What you're describing is some combination of stuff language runtimes and linkers do (shared libraries, runtime loading, JITting) and demand paging.
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.
One trick could be to run the program in a "lazy" way. E.g. don't run a statement like "a=b+c", but evaluate it only when a is needed. This would require a complete and automatic rewrite at the assembly level, but you wouldn't be doing anything that you don't need. Then from this you could determine the "hot" paths, and optimize those for speed (translate back into non-lazy form).
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.