Why dynamic is hard on static VMs:

Ruby actually requires more in the way of support than just continuations, but it's not necessarily impossible to implement on the CLR; it's just hard to implement on the CLR in a high-performing manner using today's CLR. That's part of what Jim is there to do, evolve the CLR to better support languages with Ruby's interesting featureset (like open classes and the "missing_method" method) in such a way that it doesn't tear down perf.

I've been following Less is Better, which covers implementing Ruby on the CLR. If you read there, you'll find that doing Ruby on the CLR pretty much means implementing a full VM on top of the CLR. Which tells me that the CLR is not that nice an environment for a dynamic language. The JVM is no better, and will likely remain worse. Yes, I know that there's a JSR on that. Wake me in 2015 when they get around to implementing it, and try not to asct surprised when the level of baroqueness they've added (can you say generics?) is absurd.

The bottom line is, the original designs for the CLR and the JVM did not encompass dynamic languages and the things they do. They aren't optimal for the kind of lookup a dynamic language uses for methods - in fact, they have been optimized in a different direction altogether. Then we get to continuation support - not critical for all dynamic languages, but useful if you want something like Seaside. Just look at this reasoning:

Continuations are not impossible to support, however they are currently more or less impossible to support given the current lack of access to the underlying stack frames in the managed environment--you'd need some support from the runtimes (either the JVM or the CLR) to make it work. Such runtime support would not be too difficult to add, however, as both environments already have rich and powerful stack-walking mechanisms (because both environments use the thread stack as bookkeeping tools, among other things, and need to be able to crawl through those stack markers for a variety of reasons, such as security checks), and it would not be hard to create a runtime-level mechanism that allowed code to "take a snapshot" of the stack--and its related object graph--from a certain point to a certain point, and save off that state to some arbitrary location. In many respects, it would be similar to serializing an object, I believe.

To summarize: "Continuations won't be hard on the CLR, so long as we can achieve 6 impossible things before breakfast". Sure. I'll return to what I said above - the static VMs weren't designed with this in mind, and adding it won't be easy.

Here's a simpler idea: You want the advantages of a dynamic language? Why not use a system that was designed that way? You know, right tool for the job and all that...