Change:
This PR is also a good spot to comment on my accidental commit() to master. I can make any changes to that in this PR.
This was filed a while ago (before WGLC ended), didn't want to drop it.
Editorial, design?
There is a design issue here regarding the initial congestion window that I would like to see split out into a new issue (which can be marked design). The rest appear to be things we can address with editorial changes.
NAME I moved the IW text into , though I'm not sure I think it's worth revisiting.
Thanks :) I agree that it isn't worth re-opening, but we did sign on to at least discuss whether it is worth discussing.
Do we have a plan for this one?
So, is there a plan? (Is there even anything left to do?)
Some of these are addressed already, others are in an accidental commit(), and for some there's no need to address them in the text. The rest are in
Some suggestions only.One nit, but LGTM.

Discussion:
Some networks may exhibit higher degrees of packet reordering, causing a sender to detect spurious losses.  Additionally, packet reordering could be more common with QUIC than TCP, because network <del> elements that could observe and reorder out-of-order TCP packets cannot do that for QUIC, because packet numbers are encrypted. Algorithms that increase the reordering threshold after spuriously detecting losses, such as RACK RACK, have proven to be useful in TCP and are expected to be at least as useful in QUIC. </del> <ins> elements that could observe and reorder TCP packets cannot do that for QUIC, because QUIC packet numbers are encrypted.  Algorithms that increase the reordering threshold after spuriously detecting losses, such as RACK RACK, have proven to be useful in TCP and are expected to be at least as useful in QUIC. </ins> 6.1.2.

Initial packet number space doubles the length of the timeout in the Handshake packet number space. <del> The time length of a connection that is experiencing consecutive PTOs is limited by the endpoint's idle timeout. </del> <ins> The total length of time over which consecutive PTOs expire is limited by the idle timeout. </ins> The probe timer MUST NOT be set if the time threshold (time- threshold) loss detection timer is set.  The time threshold loss

not confirmed (see Section 4.1.2 of QUIC-TLS), even if there are no packets in flight.  When the PTO fires, the client MUST send a Handshake packet if it has Handshake keys, otherwise it MUST send an <del> Initial packet in a UDP datagram of at least 1200 bytes. </del> <ins> Initial packet in a UDP datagram with a payload of at least 1200 bytes. </ins> 6.2.3.

the PTO expiry, subject to the address validation limits in Section 8.1 of QUIC-TRANSPORT. <del> Endpoints can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, a client can coalesce an Initial packet containing PING and PADDING frames with a 0-RTT data packet and a server can coalesce an Initial packet containing a PING frame with one or more packets in its first flight. </del> <ins> Endpoints can also use coalesced packets (see Section 12.2 of QUIC- TRANSPORT) to ensure that each datagram elicits at least one acknowledgement.  For example, a client can coalesce an Initial packet containing PING and PADDING frames with a 0-RTT data packet and a server can coalesce an Initial packet containing a PING frame with one or more packets in its first flight. </ins> 6.2.4.

QUIC begins every connection in slow start with the congestion window set to an initial value.  Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (max_datagram_size), <del> limited to the larger of 14720 or twice the maximum datagram size. This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP. </del> <ins> limited to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP. </ins> If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.