I haven't followed this closely, but from the surface it seems as if a couple of paragraphs in a public spec document 9 months ago could have diffused a lot of these ostensibly reasonable sounding criticisms.
Here's the Blink bug: https://code.google.com/p/chromium/issues/detail?id=309504
All of this happened in the open, in consultation with other vendors (not necessarily at WG meetings, which aren't where you design features anyway).
Remember the context here: Googlers have been doing the heavy lifting on this front for _years_. It's exciting that others are starting to pay attention to the problem space. That they don't think providing Shadow DOM to users is as urgent as we do is their right. We, however, are willing to take some pain in this (relatively small) instance, should they not be willing to help us work through the naming issue in short-order (which, as you can see from the thread, is the actual request; our goal is to improve things through web developers, preferably via collaboration.
Here's a refresher for those who missed it: https://docs.google.com/a/chromium.org/document/d/1cxW4MtsDb...
If it's ready to ship with nobody else agreeing on how it should work, please do everyone a favor and ship it with a prefix. If only as a courtesy to fellow developers who will need to deal with this mess. Nevermind that you don't want a prefix. Use one.
Better prefix hell than different implementations using the same syntax.
Being open source has never been an excuse to break the standards process. It's disheartening to see open source being used to justify this behavior again (first with PNaCl, now this).
> it'll be other vendors' pain as they have to reverse engineer Blink's implementation
Which was the salient point I was replying to. Quoting out of context to imply I made statements I did not is...disheartening.
Maybe cat/hat Shadow DOM depends on some C lib that causes incompatibility with a lib you use, which means you'll have integration problems.