Change:
This section was a holdover from when we had real version negotiation, so it assumed a bunch of actions that don't really apply in the current document. This doesn't change what is permitted, but it reframes it a little.
Section 6.3 states: I think that the text might be stale, as we no longer specify how a client should handle the payload of the Version Negotiation packet. All what we specify now is that when a client receives a Version Negotiation packet, it MUST abandon the current connection attempt.
This is still possible, it just doesn't have any effect on a version 1 client. I think that we can leave this as-is without ill effect.
I'm not sure, as the client is required to "abandon the current connection attempt" () when receiving a Version Negotiation packet, even without consulting the payload of that packet. Doesn't that prohibit the servers from sending VN packets against V1 packets, assuming that servers would prefer serving all the connections that they can accept?
We may want to change the text to say that these versions are reserved for future greasing, but yeah, I think the text needs some rework.
This feels a bit editorial -- anyone have an issue with that?
I think we have two ways forward: Drop the idea of version number greasing using 0x?a?a?a?a. Allow the servers to send Version Negotiation packets. We would need to require clients to handle it, rather than requiring them to "abandon the current connection attempt." I think it would be a design issue if we decide to pick up the latter.
Presumably clients could still use greasing version numbers, so I don't think that we necessarily need to do anything other than an editorial tweak.
Apologies, I was confused when I wrote my last comment. Yes, this can be an editorial tweak, that allows the client to respect the Version Negotiation packet, when it sends an Initial packet with a greasing version number. Or, we can leave the text as-is, claiming that the act of sending a long header packet using a greasing version number is solely governed by the invariants I-D rather than the V1 I-D.
Really, governed by whatever I-D eventually defines our version negotiation mechanism.
NAME you seem to have an idea of what to do here, can you maybe propose text? I'm not sure if we need text, but I'd be happy to look at some.
Thank you for working on this. Looks good to me.

Discussion:
6.3. For a server to use a new version in the future, clients need to <del> correctly handle unsupported versions.  To help ensure this, a server SHOULD include a version that is reserved for forcing version negotiation (0x?a?a?a?a as defined in versions) when generating a Version Negotiation packet. The design of version negotiation permits a server to avoid maintaining state for packets that it rejects in this fashion. A client MAY send a packet using a version that is reserved for forcing version negotiation.  This can be used to solicit a list of supported versions from a server. </del> <ins> correctly handle unsupported versions.  Some version numbers (0x?a?a?a?a as defined in versions) are reserved for inclusion in fields that contain version numbers. Endpoints MAY add reserved versions to any field where unknown or unsupported versions are ignored to test that a peer correctly ignores the value.  For instance, an endpoint could include a reserved version in a Version Negotiation packet; see packet-version. Endpoints MAY send packets with a reserved version to test that a peer correctly discards the packet. </ins> 7.