The overall set of steps for getting something to display in a browsing context (other than about:blank) is simplified:

1. Dispatch based on MIME type.
2. In a task:
   1. Create a document.
   2. Initialize the document and create a corresponding Window object.
   3. Update the WindowProxy slot.
3. In another task:
   1. Update the session history with the new page.

2.3 above seems wrong as that means the "unload a document" algorithm (run in 3.1) would run against the wrong global.

(It's also bogus where these tasks would actually go if the event loop is per agent cluster and we have a cross-origin navigation.)

What I think we should have by the way is more something like this (though don't let this alternative plan stop you from fixing the problem above):

1. Figure out whether to create a new global object or not and act on that.
2. Create a document in that global object.
3. Initialize the document as per MIME type and creator/parent.
4. Unload the old document and replace with the new.

1 initially seemed problematic as we don't really know whether we want a new global, but as long as we haven't switched WindowProxy and started running scripts it seems okay. And it definitely seems better to create a global first as otherwise we have to define the lazy allocation of JavaScript objects which seems silly and counter to the goal of harmonizing with JavaScript.