Code change:
I got distracted by old text and revised the introduction of semantics.
The introduction should reference the currently defined wire formats (1.1 and 2, also 1.0 maybe). We also need to figure out whether and where to mention differences: expect/continue transfer codings status phrase
Also, the current introduction to all three documents says: That needs to be adjusted to something like:
HTTP/1.2? Is there something you need to share with the working group, NAME
I think (but am not sure) that this has been covered by the changes made in Maybe NAME and NAME could have a look and see if the short HTTP/2 and HTTP/3 descriptions need more flowers.
I think that the number of flowers (->0) is entirely appropriate and I would be happy with those descriptions, with maybe a small tweak to the HTTP/3 text.
I left a review; once we resolve comments on the PR, I think this can be closed.
Some nits, but I like the direction generally.Awesome!

Related discussion:
text: 1. <del> The Hypertext Transfer Protocol (HTTP) is a stateless application- level request/response protocol that uses extensible semantics and self-descriptive messages for flexible interaction with network-based hypertext information systems.  HTTP is defined by a series of documents that collectively form the HTTP/1.1 specification: HTTP is a generic interface protocol for information systems.  It is designed to hide the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided.  Likewise, servers do not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps.  The result is a protocol that can be used effectively in many different contexts and for which implementations can evolve independently over time. HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services. </del> <ins> 1.1. The Hypertext Transfer Protocol (HTTP) is a family of stateless, application-level, request/response protocols that use a generic interface, extensible semantics, and self-descriptive messages to enable flexible interaction with network-based hypertext information systems. HTTP hides the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided.  Likewise, servers do not need to be aware of each client's purpose: a request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps.  This allows general- purpose implementations to be used effectively in many different contexts, reduces interaction complexity, and enables independent evolution over time. HTTP is also designed for use as an intermediation protocol, wherein proxies and gateways can translate non-HTTP information systems into a more generic interface. </ins> One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface.  Instead, we