Original text:
When the server can parse the client's first flight using the original version, it can extract the client's Version Information structure (see vers-info).  This contains the list of versions that <del> the client thinks its first flight is compatible with. </del>  If the server supports one of the client's compatible versions, and <del> the server also believes that the original version is compatible with </del>  this version, then the server converts the client's first flight to that version and replies to the client as if it had received the converted first flight.  The version used by the server in its reply type TRANSPORT_PARAMETER_ERROR. If the Version Information was missing, the endpoints MAY complete <del> the handshake if they have reason to believe the peer might not support this extension.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, 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. </del>  If the client received and acted on a Version Negotiation packet, the client MUST validate the server's Other Versions field.  The Other The client's first connection attempt SHOULD be made using the version that the server is most likely to support.  The client <del> selects the version it believes to be best supported from the versions that are compatible with the client's most preferred version.  Without additional information this could mean selecting the oldest version that the client supports. </del>  8.

Reviewer comments:
This draft talks about clients and servers "thinking" and "believing" things. Those verbs don't necessarily apply to protocol implementations, no matter what new frontiers we're exploring in the machine learning space. Might be worth a pass to rephrase these in terms of client or server capabilities and information. "Know" is a little fuzzier, since an endpoint does in fact possess information at certain points in the process.
So... when my computer says "thinking ...", are you saying it's lying to me?
URL

Revised text:
When the server can parse the client's first flight using the original version, it can extract the client's Version Information structure (see vers-info).  This contains the list of versions that  <ins> the client knows its first flight is compatible with. </ins> If the server supports one of the client's compatible versions, and  <ins> the server also knows that the original version is compatible with </ins> this version, then the server converts the client's first flight to that version and replies to the client as if it had received the converted first flight.  The version used by the server in its reply type TRANSPORT_PARAMETER_ERROR. If the Version Information was missing, the endpoints MAY complete  <ins> the handshake.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, 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. </ins> If the client received and acted on a Version Negotiation packet, the client MUST validate the server's Other Versions field.  The Other The client's first connection attempt SHOULD be made using the version that the server is most likely to support.  The client  <ins> selects the version most likely to be supported from the versions that are compatible with the client's most preferred version. Without additional information this could mean selecting the oldest version that the client supports. </ins> 8.