Change:
2.1. <del> The HTTP/3 specification is split into seven parts: </del> <ins> The HTTP/3 specification is split into seven parts.  The document begins with a detailed overview of the connection lifecycle and key concepts: </ins> Connection Setup and Management (connection-setup) covers how an HTTP/3 endpoint is discovered and a connection is established. <del> Stream Mapping and Usage (stream-mapping) describes the way QUIC streams are used. HTTP Framing Layer (http-framing-layer) describes the frames used on most streams. </del> HTTP Request Lifecycle (http-request-lifecycle) describes how HTTP semantics are expressed using frames. Connection Closure (connection-closure) describes how connections are terminated, either gracefully or abruptly. <del> Extensions to HTTP/3 (extensions) describes how new capabilities can be added in future documents. </del> <ins> The details of the wire protocol and interactions with the transport are described in subsequent sections: Stream Mapping and Usage (stream-mapping) describes the way QUIC streams are used. HTTP Framing Layer (http-framing-layer) describes the frames used on most streams. </ins> Error Handling (errors) describes how error conditions are handled and expressed, either on a particular stream or for the connection as a whole. <del> A more detailed comparison between HTTP/2 and HTTP/3 can be found in h2-considerations. </del> <ins> Additional resources are provided in the final sections: Extensions to HTTP/3 (extensions) describes how new capabilities can be added in future documents. A more detailed comparison between HTTP/2 and HTTP/3 can be found in h2-considerations. </ins> 2.2.

Discussion:
no text changes outside the Document Organization section.
Wow, this is a fun diff to review :-)
That's why I pointed out that there are no actual text changes. But if it's easier, you could open and in side-by-side browser windows. :-) I'd like to land this fairly quickly; from some experiments, other HTTP PRs merge into this just fine if they come after, but risk being summarily wiped out if merged before it.
It's fine. The stream usage and request "lifecycle" sections are a bit too far apart, but I don't know that I have a suggestion there.
S 3.2.2. This isn't understandable without knowing what push is or what a PUSH promise is. Am I supposed to get that from 7540? In either case, you should clearly state that a push stream can only be used for a single push promise (this is implied by the formatting). Happy to supply a PR if we can agree on what's wanted?
Yes, as currently written, a push stream corresponds 1:1 with a PUSH_PROMISE. Which is consistent again with 7540 (we had a period where it was not).
Well. A push stream corresponds one-to-one with a push ID. You can duplicate promises using the DUPLICATE_PUSH frame. I think this is what was attempted to be described by the term "promised server push" as abstract from the frames that might get sent. If the language needs to improve to make this clearer then lets do it.
Does address this sufficiently, now that the description of push precedes this section? There's already a back-reference at the end of the paragraph if someone needs more details.
Closing; please reopen if you feel that does not sufficiently address this.
It would be a lot easier to read the spec if the lifecycle (which provides an overview of operation implicitly) came before the packet formats. Happy to provide a PR, but no point if the editors don't want it.
Thanks for the suggestion. I can see this either way. The ordering was intended to follow the HTTP/2 pattern of "framing layer, putting HTTP on the framing layer." The QUIC spec's new layout of successive layers of detail (concepts, then specific mechanisms, then wire format) would suggest putting frame specifics last.

PR not necessary -- it's a straightforward change if we decide to reorder this way.
I just suggested this change the other day, because I had the same issue. In particular, talking about the multiple push frames before introducing what push is is very awkward.
I like this new layout.Thanks Mike, this works for me!