It may be the case that one could optimize for the case where a bunch of applications ship that and are statically compiled but use the same underlying libraries. In this case, some agent on the system could analyze the code segments of these binaries and on demand construct shared libraries that strip the shared portion from the binaries. Subsequent invocations would load the constructed shared libraries for redundant sections.
Still, this probably wouldn't help much and would lead to its own issues. One of the problems with these flabby things is just how the runtimes are themselves constructed. You still have per process data structures you'd need to populate and they probably have fat data structures that are not very space efficient, and so on. The size of the instructions is probably not significant relatively speaking.
Unfortunately there isn't a magic bullet to code bloat.
It helps to load the required pages into memory fast to enhance application launch times and then usual memory paging handles the rest of keeping required paths in memory.
Google says Windows\Prefetch is the directory for the cache. You could look here and see if there are any references to applications rather than just windows boot stuff.
Perhaps OSes could be smarter. After installing an app, it could monitor the "hot" paths in the code, and only load those instructions the next time the app is loaded. Also resources that are never used could be not loaded into memory. Etc. I know, it would be difficult to build this as you're basically instrumenting an app or driver and then rewriting it, but I guess it would be a great innovative feature in a time when OS research seems stagnant.