I think that [a well designed bytecode + VM modification (current JS VMs aren't really designed to run from bytecode) + implementing global cache] is more work than [creating a mapping / compiler from JS to CIL + creating a stripped down profile]. The second option does not require big redesigns, room for incompatibilities, etc. JScript.NET might have some compatibility problems, because it started before the proper DLR - a new, clean mapping would be better. Also a new mapping independent from MS would be preferable.

I don't see the problem with legacy baggage though - you don't have to ship all classes. Stripped profiles such as Compact Framework for handhelds have been already created - there's nothing stopping people from creating a new one for the web. The DLL point is a bit moot - it's just a wrapper, it works. If it's too much overhead, you can start sharing the CIL itself instead (the content is standardised afair).

You win a common execution environment. You proposed a common bytecode, but there are only so many ways in which you can implement the runtime environment in that case - each opcode has to be precisely defined. Even if each browser implemented their own, it would most likely be a complete engine redesign with very limited current code reuse. They'd have to either create everything from scratch, or reuse (for example) the DLR and CLI and implement the JS -> DLR compiler on top of them. So that's exactly what you win - not doing everything from scratch.