Original text:
ordered delivery of cryptographic handshake data start from zero in each packet number space.  Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol that is in use.

Reviewer comments:
This does a little shuffling to move some of the context-setting up. It then adds some more meat to the introductory section.
Thanks for the review Jana. I've taken most of this, with small tweaks only. Two things I didn't take: Interleaving explanation with references to sections sounded appealing, but it turns out to be both harder to read as the links break up the flow, and harder to scan for links (the structure section serves as an abbreviated and accessible ToC). I didn't move the connection piece below streams as I think that - at this level - talking about the connection is important context. I've moved the picture to the section, which didn't have that simple diagram (just some more complex ones), and I think benefits from it.
When I was reading quic-transport I found it very difficult to deal with the forward references. Streams are presented before connections, the overall state machine isn't introduced up front, packets come long after frames, and both are long before the wire formats are described. It might worth revisiting the section ordering.
At some point, transport was hugely restructured, and I believe many of those changes were good, but some didn't work out that well. I find streams coming before connections particularly odd.
The larger idea is "high-level concepts, then wire encoding" which I think makes sense. It puts the things that someone needs for a conceptual understanding of the protocol in one place, and the things that someone needs to implement the protocol elsewhere. Within the high-level concepts, I also find it strange that connections don't come before streams. However, the "connections" group also includes things that really don't deserve pride-of-place as the first couple things to be discussed, either.
I think that the main concept you need is that QUIC has a connection that is shared state between two endpoints. The later sections about connections go into more detail than you need to understand the stream sections. But I note that we don't properly provide that basic knowledge in our introductory parts, which are quite lean. Leanness is good, but we might have overdone it slightly in this regard.
Having worked my way through the spec, my suggested resolution to this is that Section 5.3 needs to be earlier, perhaps much earlier. At the least, it should open Section 5; some or all of it might belong in Section 1.
Thanks for working through this!

Revised text:
ordered delivery of cryptographic handshake data start from zero in each packet number space. <ins> fig-hs shows a simplied handshake and the exchange of packets and frames that are used to advance the handshake.  Exchange of application data during the handshake is enabled where possible, shown with a '*'.  Once completed, endpoints are able to exchange application data. </ins> Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol that is in use.