> I think we lost something with static linking when going from C to Dotnet. (And I guess Java.) Many C (and C++, especially "header only") libraries when statically linked are pretty good at filtering out unused code.

This is an interesting statement because, for example, in C version of Mimalloc you end up paying for opt-in assertions because they still exist in the code unless you compile a different version that strips them away. In C# port, you can set the same assertions/checks early with AppContext switch, and then the values will be cached in static readonly fields. Then, when JIT recompiles the code to a more optimized version, these values will become JIT constants leading to all the unreachable code to be optimized away completely (and to much better inlining of now streamlined methods).

> Even when generating a self contained EXE, the standard toolchain performs no end-linking of the program, it just bundles everything up in one file.

  /p:PublishTrimmed=true

or even

  /p:PublishAot=true # please note it's better to set it as a project property, but either way it requires non-optional linking

Lastly, consider that JITing the bytecode essentially acts like if everything is a single, statically-linked compilation unit since it's not subject to inconvenient compilation unit restrictions even Rust is subject to, the problems of which need to be cleaned up with link-time optimization.