Change:
The next Initial packet from the client uses the connection ID and token values from the Retry packet (see negotiating-connection-ids). Aside from this, the Initial packet sent by the client is subject to <del> the same restrictions as the first Initial packet.  A client can either reuse the cryptographic handshake message or construct a new one at its discretion. </del> <ins> the same restrictions as the first Initial packet.  A client MUST use the same cryptographic handshake message it includes in this packet. A server MAY treat a packet that contains a different cryptographic handshake message as a connection error or discard it. </ins> A client MAY attempt 0-RTT after receiving a Retry packet by sending 0-RTT packets to the connection ID provided by the server.  A client <del> that sends additional 0-RTT packets without constructing a new cryptographic handshake message MUST NOT reset the packet number to 0 after a Retry packet; see packet-0rtt. </del> <ins> MUST NOT change the cryptographic handshake message it sends in response to receiving a Retry. A client MUST NOT reset the packet number for any packet number space after processing a Retry packet; packet-0rtt contains more information on this. </ins> A server acknowledges the use of a Retry packet for a connection using the original_connection_id transport parameter (see transport-

Discussion:
As agreed in London and Tokyo.
We already have an editorial issue in this section; it needs breaking into subsections rather than combining long paragraphs into even longer ones. Thanks for catching the packet number thing.
I've been trying to reason about Retry and in particular the following text: This seems like it really is saying that a Retry is a new connection, and in particular that the server cannot memorize the CRYPTO from the previous Initial (which it might otherwise choose to do). I'm still trying to figure out if this is the right answer, but it seems confusing to allow the client to have both behaviors, especially as we encourage the "construct a new one". Also, if you construct a new one, could you potentially reuse the KeyShare values (might be an issue with PQ). I'm not quite sure what I think about this, but I wanted to post an issue to see if other people think it's weird and if so, maybe we should take a more prescriptive stance.
I think that it's OK to resend the same cryptographic handshake message. The semantics of Retry mean that the first wasn't used. The only thing that might be a concern is if an attacker can use this to cause two parallel connections to be established from the same ClientHello. I don't think that's possible, and the protocol is structured in a way that avoids that. (Your point about reuse and PQ does make me think that the stuff NAME was contemplating as a defense against packet injection is potentially dangerous in that context. I'm glad that there are now other approaches being contemplated for that.)
It is the same connection. Otherwise, the originalconnectionid transport parameter has no clear meaning.
What NAME says makes sense. We may want to tease out the text a bit to articulate this point, but I think it's part of the same connection establishment and therefore part of the same connection.
Tokyo conclusion: It's the same connection. We will prohibit changing the cryptographic handshake message based on receiving Retry. You can think of this as re-sending a lost Initial.
Not quite, since a retry has a fixed target DCID (stateful) whereas a lost initial has a random OCID that can reach a random server (stateless)
IIUC, we are going to require the Hello to be the same and to not reset the PN when receiving a Retry.

Assuming that is true, do we need to keep the statement that says that the server CID "MUST not be equal to the Destination Connection ID field of the packet sent by the client"? I think we can remove it now (for simplicity). See also:
NAME that requirement also exists to ensure that the server doesn't fake out the ODCID transport parameter. I think we're should keep that bit.
NAME Ah thank you for pointing out that. Agreed.
London discussion: NAME to include the last editorial bits in the spec
LGTM modulo the point below.