Original text:
since the sender will still reduce its sending rate exponentially under persistent congestion (pto).  5. At a high level, an endpoint measures the time from when a packet was

Reviewer comments:
Just in case you want to use this, I've rebased. I'll replay my suggestions too.
RFC 3390 states (and RFC 5681 has similar text): If the SYN or SYN/ACK is lost, the initial window used by a sender after a correctly transmitted SYN MUST be one segment consisting of MSS bytes. For safety reasons we should add similar text to reduce cwnd to the minimum congestion window when loss is observed/confirmed during the handshake.
NAME NAME I just spotted this deviation when reviewing a TCP issue.
Is that a fair comparison? SYN - SYN/ACK is the exchange of just two packets. A QUIC handshake will involve significantly more packets: at least 3 (ClientHello, ServerHello + Cert + SFIN, CFIN), in practice probably 4-5, depending on the size of the certificate. And even more when TLS client authentication is used.
I don't think we should change this, particularly at this point. As Marten said, there are typically multiple packets in a QUIC handshake exchange, so it's not clear to me what the best analogue would be? Also, Initial and Handshake keys can be discarded prior to ever processing an ACK, so there are cases one might not know whether the Initial or Handshake packets area lost. Also, I expect TCP SYN and SYN/ACKs are treated specially in many networks, so the odds of losing them is extra low in practice.
Let's decouple when to change anything (and if at all) from the issue discussion and its resolution. No congestion reaction to loss seems incorrect to me particularly if multiple packets are involved (which increases the probability). From point of view of network the loss of handshake packets should still be subject to a cc reaction otherwise under extreme congestion you could have collapse just due to new handshakes.
Loss does result in a reaction. My understanding is that lost packets are reported as lost, the congestion window is reduced, and a recovery period started, just like everywhere else. The TCP behaviour is analogous to detecting persistent congestion, which I suppose is the defense QUIC provides. That is consistent and seems reasonable enough to me. If that is acceptable, we could add a note explaining the difference from TCP. That is, QUIC does not treat loss of the first packets specially like TCP does, relying instead on the same loss detection and persistent congestion mechanisms that apply to all other packets; the only difference in handling is the retention of PTO during the handshake, which exists to address deadlocks caused by anti-amplification protections.
Yes, as NAME stated, detected losses trigger a reduction in the congestion window. Additionally, PTO has exponential backoff, even though the CWND does not collapse immediately. Adding a note about the differences from TCP seems sensible to me. Additionally, TCP collapses the congestion window and declares packets lost because that's how its mechanism to send a single (ie: RTO) packet works. QUIC can send a single packet without declaring packets lost or collapsing the congestion window.
As long as detected losses during handshake result in a reaction, we are good to go. Let's add clarifying text and close this. Thanks!

Revised text:
since the sender will still reduce its sending rate exponentially under persistent congestion (pto). <ins> 4.9. TCP treats the loss of SYN or SYN-ACK packet as persistent congestion and reduces the congestion window to one packet (RFC5681).  QUIC treats loss of a packet containing handshake data the same as other losses. </ins> 5. At a high level, an endpoint measures the time from when a packet was