Change:
Clarifies the cases when the PTO needs to be recomputed and possibly reset. This was not in a single place before.
NAME : merging this so it makes -28. Filing a separate issue for the leftover editorial fix.
(deleted comment, because the initially mentioned problem was incorrect. the requirement to arm the PTO timer after the handshake finishes is in Section 5.2.2)
There's some architectural inconsistency around the treatment of 1RTT PTOs at the end of the handshake. On the one hand, we are not supposed to set the PTO timer for 1RTT before the handshake is complete. This is to prevent us from retransmitting stuff the peer may not be able to process. On the other hand, we are supposed to arm the PTO timer when the handshake is confirmed. This is the point where we're guaranteed that the peer has receive keys. So there is a weird gap between handshake complete and handshake confirmed where new 1RTT packets will arm the PTO, but outstanding 0RTT or 1RTT packets from before handshake complete will not have an active PTO timer. This isn't the end of the world -- the connection will recover -- but it doesn't make any sense, and could result in either excessive PTO delays, or 1RTT probes that the peer can't decode.
NAME can we get a status update?
The PTO is always armed when there are bytes in flight(except when the loss timer is armed), it's just a matter of what PN spaces it can be armed for at a given point in time. Once the connection is handshake complete, it's immediately allowed to arm it for inflight 1-RTT ack-eliciting packets. Re-reading the text, I couldn't find anything explicitly calling out that the alarm may need to be recomputed and reset in the handshake confirmed case, though it is stated for discarding keys. As clarified in when the client is handshake complete but not confirmed, it is unsure whether the server has Handshake keys or ApplicationData keys, but it's very unlikely to have both. As such, sending something ack-eliciting from both PN spaces is safest.

Discussion:
timer expiring immediately. A sender recomputes and may need to reset its PTO timer every time an <del> ack-eliciting packet is sent.  When ack-eliciting packets are in- flight in multiple packet number spaces, the timer MUST be set for the packet number space with the earliest timeout, except for ApplicationData, which MUST be ignored until the handshake completes; see Section 4.1.1 of QUIC-TLS.  Not arming the PTO for ApplicationData prevents a client from retransmitting a 0-RTT packet on a PTO expiration before confirming that the server is able to decrypt 0-RTT packets, and prevents a server from sending a 1-RTT packet on a PTO expiration before it has the keys to process an acknowledgement. </del> <ins> ack-eliciting packet is sent or acknowledged, when the handshake is confirmed, or when Initial or Handshake keys are discarded.  This ensures the PTO is always set based on the latest RTT information and for the last sent packet in the correct packet number space. When ack-eliciting packets in multiple packet number spaces are in flight, the timer MUST be set for the packet number space with the earliest timeout, with one exception.  The ApplicationData packet number space (Section 4.1.1 of QUIC-TLS) MUST be ignored until the handshake completes.  Not arming the PTO for ApplicationData prevents a client from retransmitting a 0-RTT packet on a PTO expiration before confirming that the server is able to decrypt 0-RTT packets, and prevents a server from sending a 1-RTT packet on a PTO expiration before it has the keys to process an acknowledgement. </ins> When a PTO timer expires, the PTO backoff MUST be increased, resulting in the PTO period being set to twice its current value. <del> The PTO period is set based on the latest RTT information after receiving an acknowledgement.  The PTO backoff is reset upon receiving an acknowledgement unless it's a client unsure if the the server has validated the client's address.  Not resetting the backoff during peer address validation ensures the client's anti-deadlock timer is not set too aggressively when the server is slow in responding with handshake data. </del> <ins> The PTO backoff factor is reset when an acknowledgement is received, except in the following case.  A server might take longer to respond to packets during the handshake than otherwise.  To protect such a server from repeated client probes, the PTO backoff is not reset at a client that is not yet certain that the server has finished validating the client's address.  That is, a client does not reset the PTO backoff factor on receiving acknowledgements until it receives a HANDSHAKE_DONE frame or an acknowledgement for one of its Handshake or 1-RTT packets. </ins> This exponential reduction in the sender's rate is important because consecutive PTOs might be caused by loss of packets or