Doesn't this just push the problem up the stack one layer? Now the W3C needs to define a specification for a virtual machine that can implement all of the current web specifications performantly. If your VM is missing an API to perform some new form of user input (like multitouch) or a rendering method for a new standard (like webgl) you'll need to head back to a standards body to add more hooks, leaving us in the same position.

I think the idea has merit, but the current landscape of software development highly favours the statically compiled C++ browser engines, especially on mobile devices.

That is true, but it is much easier to accurately implement a VM spec correctly than complex high-level specs like CSS and HTML, which leave a lot of ambiguity. New hardware interfaces are also a lot easier to specify when you're talking about functions which are rarely going to be called directly by human programmers, since they will usually be accessed through higher-level frameworks.

Overall, the goal is to make implementing a browser a much simpler and direct process, and to defer as much complexity as possible to libraries which can be easily downloaded and updated. This would not only result in more a heterogeneous ecosystem for web developers, but fewer browser bugs and incompatibilities.

Complex VM? New UI metaphors? ...W3C? Sure, that spec oughta be ready in 20 years or so....

It's a vendor job, not a committee spec. They can take the arrows in the back, keep what works, toss what doesn't. I personally think that modern JS+JIT implementations are nearly fast enough: it's become the DOM and its legacy behavior that's becoming the problem now.