Consider this testcase:

<script>
  location = something;
  document.write("hello");
</script>

Per spec as currently written, the location set will stop the pageload and start a new navigation, then the write() call will stop that navigation and blow away the document, replacing it with the string "hello".

None of the shipping browsers follow the spec here:

• Chrome (release; dev builds match the spec) and Safari start the navigation async from the location set, so the write() happens before the parser is terminated and just inserts into the existing input stream, and then the navigation happens.
• Firefox sets a flag to ignore document.open and document.write on a document if https://html.spec.whatwg.org/multipage/browsing-the-web.html#abort-a-document step 3 is reached and there is an active parser at that point. So in Firefox in this case the navigation starts sync and then the write() call is just ignored.

It turns out that if the testcase is modified slightly to:

<form action="something"></form>
<script>
  document.forms[0].submit()
  document.write("hello");
</script>

there are web compat requirements that either the navigation be async or there be a flag like the Firefox one, because otherwise the form submit will not complete. See https://crbug.com/955556 for details. Right now the spec has an async navigation for form submission, but we've been considering changing that to simplify the model, in which case we'd need to add a flag like the one Firefox has.