9front does it better. No dynamic linking. At all.

User-land code can always add dynamic linking.

Not really. Would you rather that the dynamic linker-loader be part of the kernel? Do you think that the kernel can somehow prohibit user-land dynamic linking?

I would rather have it as Windows and AIX do, or even mainframes, or by gone systems of similar age like Xerox PARC or ETHZ ones, yes they are in the kernel.

In any case, modern security considerations have already shown that dynamic loading of foreign code into process memory isn't that much of a good idea after all, unless there are hardware restrictions regarding performace and memory use.

Well, I don't want dynamic linking and loading of user code to be done in the kernel -- that only increases the attack surface on the kernel.

> In any case, modern security considerations have already shown that dynamic loading of foreign code into process memory isn't that much of a good idea after all, [...]

As with many things it all depends on best practices and how you use the technology. Dynamic linking can be a big performance win. It can also be a performance loss. Dynamic linking can also be a big win in terms of code size, which even today is a good thing to have because container images can get bloated and you can need to have lots and lots of them, and it all adds up. None of that means you should be willing to dlopen() untrusted code, say.

And again, you can always implement your own dynamic linking and loading regardless of what such facilities (if any) the host OS provides.