Original text:
order of client preference.  If the list contains cipher suites the server does not recognize, support, or wish to use, the server MUST ignore those cipher suites, and process the remaining ones as <del> usual.  Values are defined in cipher-suites. </del>  Versions of TLS before 1.3 supported compression with the list of supported compression methods being sent in this field.  For every 4.2.6. <del> The "pre_shared_key" extension is used to indicate the identity of the pre-shared key to be used with a given handshake in association with PSK key establishment. The "extension_data" field of this extension contains a "PreSharedKeyExtension" value: %%% Key Exchange Messages A label for a key.  For instance, a ticket defined in ticket- establishment, or a label for a pre-shared key established externally. For each ticket, the time since the client learned about the server configuration that it is using, in milliseconds.  This value is added modulo 2^32 to with the "ticket_age_add" value that was included with the ticket, see NewSessionTicket.  This addition prevents passive observers from correlating sessions unless tickets are reused.  Note: because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds.  For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. A list of the identities that the client is willing to negotiate with the server.  If sent alongside the "early_data" extension (see early-data-indication), the first identity is the one used for 0-RTT data. A series of HMAC values, one for each PSK offered in the "pre_shared_keys" extension and in the same order, computed as described below. The server's chosen identity expressed as a (0-based) index into the identities in the client's list. Each PSK is associated with a single Hash algorithm.  For PSKs established via the ticket mechanism (NewSessionTicket), this is the Hash used for the KDF.  For externally established PSKs, the Hash algorithm MUST be set when the PSK is established. Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see psk-binder below).  If this value is not present or does not validate, the server MUST abort the handshake.  Servers SHOULD NOT attempt to validate multiple binders; rather they SHOULD select a single PSK and validate solely the binder that corresponds to that PSK.  In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity. Clients MUST verify that the server's selected_identity is within the range supplied by the client, that the server selected the cipher suite associated with the PSK, and that the "key_share", and "signature_algorithms" extensions are consistent with the indicated ke_modes and auth_modes values.  If these values are not consistent, the client MUST abort the handshake with an "illegal_parameter" alert. If the server supplies an "early_data" extension, the client MUST verify that the server's selected_identity is 0.  If any other value is returned, the client MUST abort the handshake with an "illegal_parameter" alert. This extension MUST be the last extension in the ClientHello (this facilitates implementation as described below).  Servers MUST check that it is the last extension and otherwise fail the handshake with an "illegal_parameter" alert. 4.2.6.1. The PSK binder value forms a binding between a PSK and the current handshake, as well as between the session where the PSK was established (if via a NewSessionTicket message) and the session where it was used.  Each entry in the binders list is computed as an HMAC over the portion of the ClientHello up to and including the PreSharedKeyExtension.identities field.  That is, it includes all of the ClientHello but not the binder list itself.  The length fields for the message (including the overall length, the length of the extensions block, and the length of the "pre_shared_key" extension) are all set as if the binder were present. The binding_value is computed in the same way as the Finished message (finished) but with the BaseKey being the binder_key (see key- schedule). If the handshake includes a HelloRetryRequest, the initial ClientHello and HelloRetryRequest are included in the transcript along with the new ClientHello.  For instance, if the client sends ClientHello1, its binder will be computed over: If the server responds with HelloRetryRequest, and the client then sends ClientHello2, its binder will be computed over: The full ClientHello is included in all other handshake hash computations. 4.2.7. </del> In order to use PSKs, clients MUST also send a "psk_key_exchange_modes" extension.  The semantics of this extension are that the client only supports the use of PSKs with these modes, PSK with (EC)DHE key establishment.  In this mode, the client and servers MUST supply "key_share" values as described in key-share. <del> 4.2.8. </del>  When a PSK is used, the client can send application data in its first flight of messages.  If the client opts to do so, it MUST supply an Similarly, if early data assumes anything about the connection state, it might be sent in error after the handshake completes.  4.2.8.1.  Clients are permitted to "stream" 0-RTT data until they receive the server's Finished, only then sending the "end_of_early_data" alert. In order to avoid deadlock, when accepting "early_data", servers MUST ServerHello, rather than waiting for the client's "end_of_early_data" alert. <del> 4.2.8.2. </del>  As noted in zero-rtt-data, TLS provides a limited mechanism for replay protection for data sent by the client in the first flight. %%% Record Layer <del> The cleartext of TLSPlaintext.fragment. </del>  The content type of the record. secrets and the handshake transcript.  Note that because the handshake transcript includes the random values in the Hello messages, any given handshake will have different traffic secrets, <del> even if the same input secrets are used, as is the case when +the same PSK is used for multiple connections </del>  7.1.

Reviewer comments:
This is how NSS behaves as well. This seems like a reasonable argument.
added the changes previously discussed.
I did not verify that the moved text is only move and no edits, but the other chunks seem okay.
NAME are you OK with this SHOULD?
Sounds reasonable. Mostly I just don't want to encourage servers to enforce anything about this.

Revised text:
order of client preference.  If the list contains cipher suites the server does not recognize, support, or wish to use, the server MUST ignore those cipher suites, and process the remaining ones as  <ins> usual.  Values are defined in cipher-suites.  If the client is attempting a PSK key establishment, it SHOULD advertise at least one cipher suite containing a Hash associated with the PSK. </ins> Versions of TLS before 1.3 supported compression with the list of supported compression methods being sent in this field.  For every 4.2.6.  In order to use PSKs, clients MUST also send a "psk_key_exchange_modes" extension.  The semantics of this extension are that the client only supports the use of PSKs with these modes, PSK with (EC)DHE key establishment.  In this mode, the client and servers MUST supply "key_share" values as described in key-share.  <ins> 4.2.7. </ins> When a PSK is used, the client can send application data in its first flight of messages.  If the client opts to do so, it MUST supply an Similarly, if early data assumes anything about the connection state, it might be sent in error after the handshake completes. <ins> 4.2.8. The "pre_shared_key" extension is used to indicate the identity of the pre-shared key to be used with a given handshake in association with PSK key establishment. The "extension_data" field of this extension contains a "PreSharedKeyExtension" value: %%% Key Exchange Messages A label for a key.  For instance, a ticket defined in ticket- establishment, or a label for a pre-shared key established externally. For each ticket, the time since the client learned about the server configuration that it is using, in milliseconds.  This value is added modulo 2^32 to with the "ticket_age_add" value that was included with the ticket, see NewSessionTicket.  This addition prevents passive observers from correlating sessions unless tickets are reused.  Note: because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds.  For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. A list of the identities that the client is willing to negotiate with the server.  If sent alongside the "early_data" extension (see early-data-indication), the first identity is the one used for 0-RTT data. A series of HMAC values, one for each PSK offered in the "pre_shared_keys" extension and in the same order, computed as described below. The server's chosen identity expressed as a (0-based) index into the identities in the client's list. Each PSK is associated with a single Hash algorithm.  For PSKs established via the ticket mechanism (NewSessionTicket), this is the Hash used for the KDF.  For externally established PSKs, the Hash algorithm MUST be set when the PSK is established. Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see psk-binder below).  If this value is not present or does not validate, the server MUST abort the handshake.  Servers SHOULD NOT attempt to validate multiple binders; rather they SHOULD select a single PSK and validate solely the binder that corresponds to that PSK.  In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity. Clients MUST verify that the server's selected_identity is within the range supplied by the client, that the server selected a cipher suite containing a Hash associated with the PSK, and that the "key_share", and "signature_algorithms" extensions are consistent with the indicated ke_modes and auth_modes values.  If these values are not consistent, the client MUST abort the handshake with an "illegal_parameter" alert. If the server supplies an "early_data" extension, the client MUST verify that the server's selected_identity is 0.  If any other value is returned, the client MUST abort the handshake with an "illegal_parameter" alert. This extension MUST be the last extension in the ClientHello (this facilitates implementation as described below).  Servers MUST check that it is the last extension and otherwise fail the handshake with an "illegal_parameter" alert. </ins> 4.2.8.1. <ins> The PSK binder value forms a binding between a PSK and the current handshake, as well as between the session where the PSK was established (if via a NewSessionTicket message) and the session where it was used.  Each entry in the binders list is computed as an HMAC over the portion of the ClientHello up to and including the PreSharedKeyExtension.identities field.  That is, it includes all of the ClientHello but not the binder list itself.  The length fields for the message (including the overall length, the length of the extensions block, and the length of the "pre_shared_key" extension) are all set as if the binder were present. The binding_value is computed in the same way as the Finished message (finished) but with the BaseKey being the binder_key (see key- schedule). If the handshake includes a HelloRetryRequest, the initial ClientHello and HelloRetryRequest are included in the transcript along with the new ClientHello.  For instance, if the client sends ClientHello1, its binder will be computed over: If the server responds with HelloRetryRequest, and the client then sends ClientHello2, its binder will be computed over: The full ClientHello is included in all other handshake hash computations. 4.2.8.2. </ins> Clients are permitted to "stream" 0-RTT data until they receive the server's Finished, only then sending the "end_of_early_data" alert. In order to avoid deadlock, when accepting "early_data", servers MUST ServerHello, rather than waiting for the client's "end_of_early_data" alert.  <ins> 4.2.8.3. </ins> As noted in zero-rtt-data, TLS provides a limited mechanism for replay protection for data sent by the client in the first flight. %%% Record Layer  <ins> The byte encoding of a handshake or an alert message, or the the raw bytes of the application's data to send. </ins> The content type of the record. secrets and the handshake transcript.  Note that because the handshake transcript includes the random values in the Hello messages, any given handshake will have different traffic secrets,  <ins> even if the same input secrets are used, as is the case when the same PSK is used for multiple connections </ins> 7.1.