> by saying it would end up with the same limitations as the JVM
No, they were saying that it would end up with a different set of limitations, and gives the JVM as an example. E.g. if you exposed the current Dart VM's feature set as a byte code VM, ML folks would complain it doesn't support tail calls, Haskell folks would complain it doesn't allow them to efficiently encode their TABLES_NEXT_TO_CODE optimization, etc. Java folks would complain it's integer semantics are wrong (overflow to bignum rather than wrap-around), that it lacks support for arbitrary class loading, etc.
And, as Nutter points out, the JVM isn't nearly as constrictive to other languages as people seem to think it is, despite being designed only for one language.
So, with everything we've learned about VM design since then, and with the explicit goal of supporting multiple static and dynamic languages, you would think that we could design a pretty good bytecode VM for the browser today. It may not be the ideal VM for every language, but it could probably be ideal for a lot of them, and adequate for the rest. A Dart source interpreter won't be ideal for any of them.
As for their "case for a language VM" i.e. inline code, there's a simple solution to that: support both bytecode and inline code. Source is going to get minified anyway, before it goes into production, so you might as well let them compile it to bytecode. Other languages will support inline code by implementing their compilers for the browser, just like CoffeeScript does.
No, they were saying that it would end up with a different set of limitations, and gives the JVM as an example. E.g. if you exposed the current Dart VM's feature set as a byte code VM, ML folks would complain it doesn't support tail calls, Haskell folks would complain it doesn't allow them to efficiently encode their TABLES_NEXT_TO_CODE optimization, etc. Java folks would complain it's integer semantics are wrong (overflow to bignum rather than wrap-around), that it lacks support for arbitrary class loading, etc.