Is there really a need to support async?  It's much better to limit it to <script defer>-like behavior (which is what you described for b.html and c.html), where loading doesn't block but things always happen in the same order.  Web APIs shouldn't be nondeterministic.

Unlike <script>, imports machinery has many reasons to be used by non-async [1].
@async is for things that are self contained and don't care about the order.
It is as to no blocking other things.
If the order is a concern, sync is better option.

[1] https://gist.github.com/omo/9986103

I'm not saying it shouldn't support asynchronous loading, I'm asking whether it should really support the <script async> model instead of the <script defer> model.

<script async> means "load the resource asynchronously, and run the script as soon as it's ready".  <script defer> means "load the resource asynchronously, and run the script in the order it was added (at the end of parsing)".  If you have multiple <script defer>s, they all load asynchronously, but later ones don't execute until earlier ones, even if the network load happens to finish first.

With the defer model, b.html, c.html, a.html and d.html would always be executed in that exact order (sync before defer, then defer in the order added), which is much easier to test--you don't have to test every possible load order to be certain your page always works, since the load order is always predictable.

It seems like <script async> was a bad idea which <script defer> fixed, and now this is making the same mistake.

(In reply to Glenn Maynard from comment #3)
> <script async> means "load the resource asynchronously, and run the script
> as soon as it's ready".  <script defer> means "load the resource
> asynchronously, and run the script in the order it was added (at the end of
> parsing)".  If you have multiple <script defer>s, they all load
> asynchronously, but later ones don't execute until earlier ones, even if the
> network load happens to finish first.
> 
> With the defer model, b.html, c.html, a.html and d.html would always be
> executed in that exact order (sync before defer, then defer in the order
> added), which is much easier to test--you don't have to test every possible
> load order to be certain your page always works, since the load order is
> always predictable.
> 
> It seems like <script async> was a bad idea which <script defer> fixed, and
> now this is making the same mistake.

<script async> is bad idea because there is no way to declare the dependency to the loaded script. For imports, the import itself can contain a set of imports to require its dependency. So it's much easier for imports to be self contained. This is big difference between <scripts> and imports.

Imports support textual ordering mainly for consistency of other platform bits. Imports shouldn't have to rely on that ordering and so do not well defined imports. Dependency is no longer have to be a list. Now it can be a tree.

One good thing not to enforce ordering for @async is that imports that is loaded faster can rendered earlier, without waiting other imports. This is important for mashup-like scenario. Tweet buttons don't to Like buttons and vice versa.

By the way, I understand the unpredictability concern.
That's why we're polishing sync scenario so that it blocks as little as possible.

Moved to https://github.com/w3c/webcomponents/issues/218