Change:
NAME fixed up IAW with your comments. PTAL
It is necessary to specify how retry works when a compatible upgrade is used. The easiest way to specify this is to say that Retry can be sent in version 1, but the validation is performed as though a version 2 retry was sent. That's what I've seen implemented thus far.
Here's the relevant text in your PR (numbers mine) (1) A server SHOULD produce a Retry packet in the same version as the Initial packet that the Retry packet responds to. (2) Validation of the Retry exchange uses the logic of the final negotiated version, treating the Retry as if it were sent in that version. (3) This means that the version used for Retry is not authenticated, only that it occurred and the connection ID that was used. (1) I made it a MUST in the recent merge, to make it a bit easier for clients. (2) I'm not really sure what this means in the context of v1/v2 -- the logic is identical in both cases. Maybe this is something for the v1->vn text (pending) in the VN doc? But yeah, anything in the client hello, including the retry TPs, are processed syntactically as v1 but the content is used for v2 purposes. Do I understand the takeaway correctly? (3) This is a fair point to make, I guess: the Retry logic only ever measured that the CIDs matched. But, meh? The client changing the version between connection attempts would be strange, but legal and not obviously dangerous. If you think this sentence is valuable, I can add it.
Fine. Yeah, this was just a wording choice of mine. I do think that the validation is an important point to be clear on, lest people decide to skip it. I don't think that this can be part of the VN document at least as it stands as the Retry mechanism is version-specific and so any handling of it also needs to be. This is really just noting the limitations of the validation. I don't think that it has security consequences, particularly if the client enforces the requirement that Retry use the original version (which, presumably they are permitted to... by dropping the packet).
URL is going to introduce some considerations specific to v1. Nevertheless, I'm happy to write something down here.

Discussion:
same requirements in either direction.  This section uses the terms "original version" and "negotiated version" from QUIC-VN. <del> If the server elects to send a Retry packet, it MUST do so using the original version. </del> <ins> If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets using other versions.  The client MUST NOT use a different version in the subsequent Initial that contains the Retry token.  The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched. QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1.  After switching to a negotiated version after a Retry, the server MUST include the relevant transport parameters to validate that the server sent the Retry and the connection IDs used in the exchange, as described in Section 7.3 of QUIC.  Note that the version of the first Initial and the subsequent Retry are not authenticated by transport parameters. </ins> The server SHOULD start sending its Initial packets using the negotiated version as soon as it decides to change.  Before the