I'm suggesting if people in the appropriate working group feel as if a particular solution to a problem (regardless of how old the problem is) wasn't given due consideration, the notion of "speak now or we'll ship anyway" is not productive. I don't believe that Google in particular is a bad actor in the standards community. Far from it! I do feel as if something as fundamentally paradigm-shifting as Web Components needs care and thought to be done correctly and respectfully. Saying "we're going to ship this solution ASAP, any last-minute objections" puts unnecessary stress and time constraints on the task of making the best, most useful solution possible.
Progress delayed is progress denied. If you want a better web platform, that means wanting one that is different than the one we have today. It is also the case that standards committees are not outfitted with effective fitness functions (the ability to predict market success, e.g.). The best we can do is to iterate and be data-driven. I do not know what "correctly" means in this context, and I submit that you don't either. What we _are_ doing is making the progress we can with the best available data we can gather (polyfilling via Polymer, building large-scale apps, observing existing libraries and their challenges, etc.). It's fine to critique the method, but bring data.
If you have specific concerns regarding their utility or design of these specs, I'm hopeful they can be aired as we continue to iterate. Shipping is not the end; it's a new beginning.
Then do everyone a favor and namespace your apis so it's obvious they are not standards compliant and can be cleanly used at the same time as other browser implementations until the standard is ready.
Meaningful progress is progress for the most people. To achieve that, it's often most effective to create coalitions to help you achieve that progress in areas you yourself cannot. This is where collaboration and standards come in.
What's going on now is a request for collaboration. It has been somewhat de-railed, but I have hope. Barring consensus, we feel the risks are outweighed by the gains for developers in having changed things in the bit of the world our codebase addresses.
Perhaps you weren't looking for a real answer, but there's one anyway.
