Change:
This addresses some questions about use of multiple tokens, as well as cleaning up the text adjacent in minor ways.
The spec doesn't define what is a client is supposed to do when it receives multiple NEWTOKEN frames. There seem to be multiple reasonable ways to handle this situation: A client could always use the oldest token first. This would allow the client to establish multiple connections at the same time. A client could replace any old tokens when receiving a new token. This has the advantage that the most recently issued token will (presumably) have the longest life time. Furthermore, if the server encodes connection statistics (RTT, cwnd, etc.) into the ticket, using the newest ticket would provide it with the most recent data. From the Slack discussion, a better way might be a combination of these two: When establishing a new connection, use the most recently obtained token first. When establishing another connection to the same server (before receiving a new NEWTOKEN), use an older token. Client might then want to remember n tokens per endpoint, if they expect to establish n new connections simultaneously (or a few more than n, depending on the network conditions, to account for failed connection establishments).
Your suggestion SGTM.
This is fine, and it merely reflects reality: older tokens are less likely to be useful. But there is no harm in attempting to use any token, provided that it hasn't been used before.
Do we need text about that? NAME do you want me to prepare a PR?
I think that an editorial PR would be great. This is advice that doesn't change interoperability.
Some suggestions, but looks good.

Discussion:
the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. <del> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. </del> <ins> A token SHOULD be constructed in a way that allows the server to distinguish it from tokens that are sent in Retry packets as they are carried in the same field. </ins> The token MUST NOT include information that would allow it to be linked by an on-path observer to the connection on which it was

A client SHOULD NOT reuse a token in different connections.  Reusing a token allows connections to be linked by entities on the network <del> path (see migration-linkability).  A client MUST NOT reuse a token if </del> <ins> path; see migration-linkability.  A client MUST NOT reuse a token if </ins> it believes that its point of network attachment has changed since the token was last used; that is, if there is a change in its local IP address or network interface.  A client needs to start the <del> connection process over if it migrates prior to completing the handshake. </del> <ins> connection process over if there is any change in its local address prior to completing the handshake. Clients might receive multiple tokens on a single connection.  Aside from preventing linkability, any token can be used in any connection attempt.  Servers can send additional tokens to either enable address validation for multiple connection attempts or to replace older tokens that might become invalid.  For a client, this ambiguity means that sending the most recent unused token is most likely to be effective.  Though saving and using older tokens has no negative consequences, clients can regard older tokens as being less likely be useful to the server for address validation. </ins> When a server receives an Initial packet with an address validation token, it MUST attempt to validate the token, unless it has already