My thoughts, which I've repeated in a few different forums already:
The underlying mechanisms for the CLR as well as for the JVM *are* dynamic. The problems for making these systems universal are in the necessity to use nearly the entire language model of C# or Java, rspectively, in order to achieve any kind of integration.
A better approach, IMHO, would be to make integration more abstract and more loosely coupled than the "shared object model" of the CLR or JVM.
Components written in various languages should be integrated via a simpler, asynchronous, shared-nothing, message passing model. Then those components could be instantiated in the same OS process, a different OS process, or on a distinctly different host on the network, without having to alter the mechanism for integration.
A virtual machine in this model would offer a reusable implementation of garbage collection, component instantiation, time-sharing, channel discovery, message formatting, optimized "intra-OS-process" message passing, and an instruction set for sequential processing. A universal virtual machine would not require a shared-memory, monitor-based, object model.
I would choose Scheme as the "instruction set" of my virtual machine, and not make language implementors deal with low level CPU models.