I've been putting off a response on this, but I have some things to add... The topic on this thread was originally HTML Imports - it seems like some of the concerns expressed extend beyond imports and are a little wider ranging. I am cross posting this comment to public-next...@w3.org as I think it is related.
I share the concern about letting out an API too early, but I think my concerns are different. In the past we worked (meaning browsers, devs, stds groups) in a model in which things were released into the wild - prefixed or not - without a very wide feedback loop. At that point, the practical realities leave not many good options for course correction or even for small, but significant tweaks. I think a lot is happening to change that model and, as we can see in the case of everything with Web Components (esp imports and selectors perhaps) the wider we throw the net the more feedback we get from real people trying to accomplish real things with real concerns - not just theory. Some of this experimentation is happening in the native space, but it is behind a flag, so we are shielded from the problems above - no public Web site is relying on those things. And some of that is happening in the prollyfill space - Github FTW - in projects like x-tags and polymer. When we really look down through things it does feel like it starts to become clear where the pain points are and where things start to feel more stable. With this approach, we don't need to "rush" standardization in the large scale - if we can reasonably do it without that and there seems to be wide questioning - let's hold off a bit. HTML Imports, for example, are generating an *awful* lot of discussion - it feels like they aren't cooked to me. But virtually every discussion involves elements we know we'd need to experiment in that space - modules would allow one kind of experimentation, promises seem necessary for other kinds, and so on. There is a danger of undercooking, yes - but there is also a danger in overcooking in the standards space alone that I think is less evident: No matter how good or bad something is technically, it needs uptake to succeed. If you think that ES6 modules have absolutely nothing to do with this, for example, but through experimentation in the community that sort of approach turns out to be a winner - it is much more valuable than theoretical debate. Debate is really good - but the advantage I think we need to help exploit is that folks like Steve Souders or James Burke and W3C TAG can debate and make their cases with working code without pulling the proverbial trigger if we prioritize the right things and tools to make it possible. And no ones code needs to break in the meantime - the JS-based approach you use today will work just as well tomorrow - better actually because the perf curve of the browser and speed of machines they run on is always up. I don't think that "perfect" imports is necessarily the lynch-pin to value in Web Components - it needn't block other progress to slow down the standard on this one. Other things like document.register already feel a lot more stable. Finding a way to evolve the Web is tricky, but I think doable and the Web would be a lot better for it if we can get it right.