Original text:
Version Negotiation packet.  This packet SHALL include each entry from the server's set of Offered Versions (see server-fleet) in a Supported Version field.  The server MAY add reserved versions (as <del> defined in the Versions section of QUIC) in Supported Version fields. </del>  Upon receiving the VN packet, the client will search for a version it supports in the list provided by the server.  If it doesn't find one, QUIC version 1, that connection closure MUST use a transport error of type "VERSION_NEGOTIATION_ERROR". <del> If a client has reacted to a Version Negotiation packet, it MUST validate that the server's "Other Versions" field does not contain the client's original version, and that the client would have selected the same negotiated version if it had received a Version Negotiation packet whose Supported Versions field had the same contents as the server's "Other Versions" field.  If any of these checks fail, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type "VERSION_NEGOTIATION_ERROR".  This connection closure prevents an attacker from being able to use forged Version Negotiation packets to force a version downgrade. </del>  After the process of version negotiation in this document completes, the version in use for the connection is the version that the server

Reviewer comments:
In light of discussion in slack, the problem here is that the validation is based on the negotiated version. Validation needs to be based on the client's selected version. I've also moved text about validating lack of support for the original version to the incompatible VN section, alongside a reminder to validate connection IDs. Security does depend on this, but the client ignores these bad VN packets. That provides more effective defense against attack than what was here originally.
Thanks! Approved modulo two nits

Revised text:
Version Negotiation packet.  This packet SHALL include each entry from the server's set of Offered Versions (see server-fleet) in a Supported Version field.  The server MAY add reserved versions (as  <ins> defined in Section 6.3 of QUIC) in Supported Version fields. Clients will ignore a Version Negotiation packet if it contains the original version attempted by the client.  The client also ignores a Version Negotiation that contains incorrect connection ID fields; see Section 6 of RFC8999. </ins> Upon receiving the VN packet, the client will search for a version it supports in the list provided by the server.  If it doesn't find one, QUIC version 1, that connection closure MUST use a transport error of type "VERSION_NEGOTIATION_ERROR".  <ins> If the client received and acted on a Version Negotiation packet, the client MUST validate the server's "Other Versions" field.  The "Other Versions" field is validated by confirming that the client would have attempted the same version with knowledge of the versions the server supports.  That is, the client would have selected the same version if it received a Version Negotiation packet that listed the versions in the server's "Other Versions" field, plus the negotiated version. If the client would have selected a different version, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type "VERSION_NEGOTIATION_ERROR".  This connection closure prevents an attacker from being able to use forged Version Negotiation packets to force a version downgrade. This validation of "Other Versions" is not sufficient to prevent downgrade.  Downgrade prevention also depends on the client ignoring Version Negotiation packets that contain the original version; see incompat-vn. </ins> After the process of version negotiation in this document completes, the version in use for the connection is the version that the server