Your item 1 is obviously problematic. If Dart and JS have close semantics, it's just a transpiler like CoffeeScript, which intentionally sugars JS semantics with leaner syntax.
But this does not match the leaked info and hype about Dart, and even then, such warm beer still requires you to run a tool over your primary source, which costs adoption. Lots of languages already contending in this transpiling space.
More likely, a Dart-to-JS compiler (making non-local transformations) and a JS-implemented Dart runtime (to support the novel runtime semantics, e.g. new numeric types) will be required.
This means a worse user experience in browsers that don't have the native Dart VM, because performance will lag (especially depending on the new numeric type details) and bug-for-bug compatibility will be lost.
The native VM will be the super-fast source of truth. The compiler/runtime will be a stop-gap. This brings us back to the standards table, unless the idea is to corner the browser market. See
under "On Dart: ..." about what the standards table would look like if it is anywhere near today's mix of browser vendors and other interested parties.