Dart is OSS, so I geuss if it really got mass adoption, Firefox and IE could adopt it. Yes, this would lead to a single implementation, I'm not sure how I feel about this. On the one hand, it limits innovation from multiple implementations, on the other hand, incompatibilities between implementations, have been a big source of programmer headache in the first place. Flash was not bad in that respect and is one reason for it's success, despite its shortcomings. I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore.
Really though, Brendan has made the argument that Javascript is fixable and that it is a good target for higher level languages, and I don't really agree with either of them.
The changes I see being planned for ES.next don't really address some of the fundamental problems with JS, like network transport, or startup costs because of legacy constraints of not wanting to break existing JS. On mobile devices, loading a lot of Javascript is expensive, and I don't see anything in ES.next to bring it anywhere near competitive with native. If mobile is the future and the predominant way we consume the web, then we are at big risk of being dominated by native. Can we afford to wait years more for a promised fix that isn't even in sight?
For a mobile device, ideally you'd want a dynamic language that could be atleast partially statically optimized for a particular device platform, and transmitted in a highly compact format that is cheap to parse and execute on a mobile VM to not make the device waste bandwidth or precious battery performing tasks that could be done on the server for it (like executing a parse and eval)
Likewise, I don't agree that JS is an ideal intermediate format for higher level languages to compile to. I'm not saying LLVM or JVM bytecode are either, but if your HLL contains numerics like 64-bit ints or longs, for example, it's pretty crappy to translate. There's also double costs here: You're running a HLL compiler to parse, compile, and optimize one language, which then must be parsed, evaled, and optimized a second time on your target CPU.
Something like DVM, or a bytecode specifically designed for JS would be better I think.