Here's a stab at a more operational algorithm that I think might be feasible:

There is a DOCUMENT QUEUE.

Each document has a BASE ELEMENT QUEUE.

When the parser pops an Custom Element, frazzle the element.

Additionally, when a <link rel="import" ...> is inserted into a document, frazzle that element too.

To frazzle ELEMENT:

If ELEMENT's owner document is not in DOCUMENT QUEUE:
  Insert ELEMENT's owner document into DOCUMENT QUEUE
If ELEMENT is not in owner document's BASE ELEMENT QUEUE:
  Insert ELEMENT into owner document's BASE ELEMENT QUEUE

At a microtask checkpoint:

For each DOCUMENT in DOCUMENT QUEUE:
  If DOCUMENT "is an import"*:
    Skip DOCUMENT
  Otherwise:
    Process DOCUMENT's BASE ELEMENT QUEUE

* Being an import is a dynamic condition. If the <link> tag that begot you orphans you, you're not an import any more?

(I didn't do any DOCUMENT QUEUE emptying. The BEQs become empty so repeatedly processing them is a no-op. But an implementation would remove a document that has finished parsing from the DOCUMENT QUEUE.)

To process a BEQ:

For each ELEMENT in BEQ, in order:
  If ELEMENT is an IMPORT:
    If ELEMENT has an imported document:
      Process the ELEMENT's imported document's BEQ (ie recurse).
    If the ELEMENT's IMPORT READY FLAG is not set:
      Stop these steps. Commentary: Everything (including the link
      element) is left in BEQ for next time.
  Remove ELEMENT from the BEQ
  Process ELEMENT's associated CALLBACK QUEUE (if any)

Commentary:

There are complicating factors motivating this craziness:

- <link rel="import" ...> can be inserted and removed, bringing multiple documents into existence as it does so (I think?) so we need the document queue as a catch-all to make sure we eventually start calling people's callbacks.

- <link rel="import" ...> doesn't necessarily have an associated document, so we need to use the link tags themselves to keep track of things.

The ordering is going to be defined, but extremely wild, if you move a link tag (particularly to a different document.) The wildness if because we use a link tag to find a document to recurse to, but that might not be the one begotten from that insertion; time might have marched on? You get what you deserve.

(In reply to Dominic Cooney from comment #0)
> Maybe I just don't understand the set of related specs well enough, but I
> don't see anything which stops custom element processing in a given document
> running ahead of imports in that document. The base element queue is sorted,
> and things are enqueued in it in a certain order, but it is unclear given:
> 
> <x-a>
> <link rel="import" href="two.html">
> <x-b>
> 
> two.html:
> ...
> <x-c>
> ...
> 
> that x-a, x-b, x-c isn't a valid order provided that x-a, x-b are run at one
> microtask checkpoint and x-c is run at another.

You're right! If:

1) the queue is in this state: [ x-a, @, x-b ], where "@" is the import that has not loaded,
2) parser yields and the microtask checkpoint occurs,
3) the callbacks for x-a and x-b will be invoked, and x-c will be invoked later.

(In reply to Dominic Cooney from comment #1)

In spec, I think I can express this in just a few sentences. Let me give it a shot.

> Commentary:
> 
> There are complicating factors motivating this craziness:
> 
> - <link rel="import" ...> can be inserted and removed, bringing multiple
> documents into existence as it does so (I think?) so we need the document
> queue as a catch-all to make sure we eventually start calling people's
> callbacks.

Adding and removing import links imperative means that:
1) we're no longer operating on base element queue, and
2) all fetches are synchronous

This helps greatly, since this makes all these operations atomic and we don't need to worry about stability of order (or ordering at all).
 
> - <link rel="import" ...> doesn't necessarily have an associated document,
> so we need to use the link tags themselves to keep track of things.
> 
> The ordering is going to be defined, but extremely wild, if you move a link
> tag (particularly to a different document.) The wildness if because we use a
> link tag to find a document to recurse to, but that might not be the one
> begotten from that insertion; time might have marched on? You get what you
> deserve.

I think it's same as above. I could be wrong. This is complicated stuff :)

https://dvcs.w3.org/hg/webcomponents/rev/ae75ca747696, WDYT?