Given that the different processes have different event loops, in what sense does the current ordering not allow the implementation strategy you describe?

The following text:

"All BroadcastChannel objects whose BroadcastChannel settings objects specify a responsible document contained within a particular top-level browsing context must be sorted in the same relative order as the order that those Document objects are listed in the list of the descendant browsing contexts for the active document of that top-level browsing context."

This requires that BroadcastChannel objects coming from the same top-level browsing context, but from different Documents, have a particular sorted order. This order does not always match the creation order.

I.e. I can't make all BroadcastChannels from the same process simply be sorted in creation order.

Ah, yeah. The idea here would be that for each browsing context you would just walk the tree of frames and handle each one in turn. Is it easier to do it for all frames at once? I don't mind either way; this was just intended to make it easier to implement. (Same with the order of auxiliary windows — the idea was to match the order that the windows would have internally, assuming they are ordered in creation order.)

At least in gecko it would indeed be easier to do for all frames at once. At least all frames in the same eTLD+1 since those are guaranteed to be in the same process.

Ok! Well, since you're the first implementor, you get to pick the order. :-)

Checked in as WHATWG revision r8593.
Check-in comment: Change the sort order for broadcast channel messages to be easier to implement
http://html5.org/tools/web-apps-tracker?from=8592&to=8593