Original text:
unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is, the client MUST set the probe timer if the client has not received an <del> acknowledgement for one of its Handshake or 1-RTT packets. </del>  Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to

Reviewer comments:
Having non-overlapping conditions makes sense; adjusted wording.
The recovery draft : This is consistent with the pseudocode, in particular . When the server receives the client's final handshake flight, it discards handshake keys and hence cannot acknowledge it. When the client receives the resulting , the handshake is confirmed, but no Handshake or 1-RTT acknowledgements have necessarily been received. This results in a PTO being set even though the client's address has certainly been verified and there are no ack-eliciting packets in flight. As written, the pseudocode would in fact set a PTO for the Initial space at a garbage time. I think this could be corrected by appending "and has not discarded handshake keys" or "and has not confirmed the handshake" to the language, and adding the analogous clause to the conditions checked in the final statement of .
I thought that was implied, but implications are bad, so I agree it's best to explicitly state it. I'm happy to review a PR if you have time to write one, or I'll fix this fairly soon ideally.
When a reverse proxy forwards a HTTP response to the client, sometimes it sees the upstream server terminate the response early. For example, a HTTP/1.1 connection being closed prior to transmitting number of bytes specified by the field. Or a chunked response being closed abruptly. The only way of delegating such a condition to the client in HTTP/2 was to send a RSTSTREAM frame with . However, use of the error code is awkward in this case, considering the fact that the error did not happen within the communication between the endpoints using the particular HTTP/2 connection. I think it makes sense to have an error code that better designates the case. One way to address the issue in H3 would be to change to , and let the server use the error code (as an argument of the RESET_STREAM frame) to indicate that the response has been "cancelled". Originally proposed in URL
What if you do not want to admit to being a proxy? (who does?)
HTTPMESSAGECANCELLED would simply mean that the transfer of the response is cancelled, regardless of the server being an origin or a reverse proxy.
I can get behind this. As long as we're not looking for a byte-by-byte reproduction of the bytes the intermediary received (as was once requested and rejected, I think at the Seattle interim), then it makes sense to signal that the message was killed.
This is basically an expansion of the CANCELLED/REJECTED codes to allow a server to do either. WFM.
NAME Yes. And thank you for the PR.

Revised text:
unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is, the client MUST set the probe timer if the client has not received an  <ins> acknowledgement for one of its Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame. </ins> Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to