(I don't know why I keep wandering into this thread; I don't even like Dart, but here goes...)
We agree that the browser market of 1995 is not one we want to replicate, but the rest of this is revisionist to a fault. The development of the open web itself has consistently been a messy business. There's a reason that the single-champion model has been adopted by several groups, including TC39: it works really well, and a lot of good standards have come out of it, whether on purpose (many recent specs) or not (many of the features we can thank old IE for). Even when things have been going great, people try to use committee maneuvering to torpedo things, or patent claims come out of the blue and suddenly you're turning to a different champion for your touch events.
Pretending that we now have a one true way of developing the open web is silly, because it's not even a little true.
> The Canvas spec is a complete steaming pile of nonsense that again, has only been iteratively improved into a more useful state by the tireless efforts of the whatwg (and whoever was maintaining it before them, I don't remember). Canvas delivers miserable performance and a crippled, arbitrary feature set that was clearly designed for the specific purpose of solving whatever problems Apple had at the time. Compare Canvas with WebGL, if you like: WebGL was developed in the open, based on an established, proven API that had been used to solve problems for decades, and it is quickly gaining on Canvas for many use cases due to that - even though it's lower-level, harder to use, and less widely supported.
The canvas spec is extremely well thought through because it's an API that was copied virtually verbatim from CoreGraphics/Quartz2d, which has a lineage that's been hammered on since QuickDraw came on the scene. What it is, however, is out of date in a world that is constrained on bandwidth to the GPU, but has computation power to spare once there. Apple has worked hard to efficiently implement Quartz2d on top of modern GPUs, but, yes, it's silly for everyone else to spend as much energy as they have bending over backwards for something inherently less efficient. The spec is slowly being brought up to speed.
Meanwhile, WebGL, which has indeed been a model of open development, would of course have been similarly hampered if it had come a little earlier and been based on OpenGL ES 1.0 (though less so than Canvas), but it also proves my point: Khronos is a famously not open standards body, incredibly bound by the patent and disclosure agreements that the member organizations require of them, and though the WebGL group has done more than admirably in that environment (even driving changes on what should be common-sense notions like conformance tests), the spec that WebGL is based on, OpenGL ES 2.0, was produced in that closed environment on private lists, and is especially favored because it discards its decades of legacy.
WebGL is "gaining" on canvas (whatever that means) because it enables a whole world of high performance effects (3d and otherwise) that were before impossible. And this largely in spite of the API, which was of course designed not to favor usability or abstract the hardware, but to be an efficient foundation for the type of libraries like three.js that have been driving the popularity.
> You don't have to announce a project the day you start working on it, and there's a huge difference between announcing an idea or an initiative with a proof-of-concept and what Google did with NaCL and Dart, where something was announced along with the intent to ship it as a built in special-purpose binary blob in the browser and expose it to the web, regardless of the thoughts or intents of web standards folks and the community at large.
Neither of these things are true, and you don't even have to search very hard to verify it. NaCl is the farthest from your description, as it was released as an initial proof of concept via a browser plugin[1] and even ran in Firefox, Safari, and Opera at the time. Pepper is what most open standards objections revolve around, as there has never (AFAIK) been an effort to standardize it in spite of its very long development time (beyond some early initial discussions with Mozilla[2]), but its actual development has indeed always been in the open as part of the chromium code base.
As for Dart, there was an initial "surprise" unveiling for the language, but my understanding is that there have been significant changes in the core libraries in response to community feedback (in the language itself as well? no idea). And, of course, there's the small detail that it has never actually shipped as a special-purpose binary blob in a browser and been exposed to the web. They certainly don't get points for maybe someday moving Dart to a standards body, and so they certainly aren't harming the web for maybe, someday shipping Dart in a browser.
[1] http://googlecode.blogspot.com/2008/12/native-client-technol...
[2] https://wiki.mozilla.org/index.php?title=NPAPI:Pepper&oldid=...