Original text:
when it was able to find an acceptable set of algorithms and groups that are mutually supported, but the client's KeyShare did not contain an acceptable offer.  If it cannot find such a match, <del> it will respond with a "handshake_failure" alert. </del>  Structure of this message: [[OPEN ISSUE: Merge in DTLS Cookies?]] <del> The group which the client MUST use for its new ClientHello. </del>  <del> The "server_version", "cipher_suite" and "extensions" fields have the same meanings as their corresponding values in the ServerHello.  The </del>  server SHOULD send only the extensions necessary for the client to <del> generate a correct ClientHello pair. </del>  Upon receipt of a HelloRetryRequest, the client MUST first verify <del> that the "selected_group" field corresponds to a group which was </del>  provided in the "supported_groups" extension in the original <del> ClientHello.  It MUST then verify that the "selected_group" field does not correspond to a group which was provided in the "key_share" </del>  extension in the original ClientHello.  If either of these checks fails, then the client MUST abort the handshake with a fatal "handshake_failure" alert.  Clients SHOULD also abort with was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). <del> Otherwise, the client MUST send a ClientHello with a new KeyShare extension to the server.  The client MUST append a new KeyShareEntry list which is consistent with the "selected_group" field to the groups in its original KeyShare. </del>  Upon re-sending the ClientHello and receiving the server's ServerHello/KeyShare, the client MUST verify that the selected CipherSuite and NamedGroup match that supplied in the <del> HelloRetryRequest. </del>  [[OPEN ISSUE: https://github.com/tlswg/tls13-spec/issues/104]]

Reviewer comments:
NAME You addressed the main ambiguity in URL . This fixes a few remaining issues. An itemized list: "handshakefailure" alert is fatal note it must be appended, not just "used", in the selectedgroup description (just using instead of appending creates a downgrade attack due to lack of authentication for this message, as discussed previously) clean up styling of variable names; the dominant style uses no quotes around variable names, but quotes around enum values (granted, this may not be the ideal style, but it is more or less consistently the case elsewhere in the document) note that the same rule as ServerHello applies: no extensions the client did not offer first update text to deal with possibility of omitted extension minor wording simplification specify error to use if "MUST" fails (could be a "SHOULD" error, here)
NAME Repushed commit with changes for comments. Changed description to not say used/amended, but rather describe what it actually represents directly: the group the server intends to negotiate and is requesting a retry for. (we don't need duplicated MUSTs here, and stating its actual meaning more explicitly is preferable) Changed text wrt selected group as suggested.
Rebased on top of PR (which still merges cleanly onto master, as of this moment; this does too) to avoid flip-flopping again on the omit vs. empty KeyShare for retry request.

Revised text:
when it was able to find an acceptable set of algorithms and groups that are mutually supported, but the client's KeyShare did not contain an acceptable offer.  If it cannot find such a match,  <ins> it will respond with a fatal "handshake_failure" alert. </ins> Structure of this message: [[OPEN ISSUE: Merge in DTLS Cookies?]]  <ins> The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for. </ins>  <ins> The server_version, cipher_suite, and extensions fields have the same meanings as their corresponding values in the ServerHello.  The </ins> server SHOULD send only the extensions necessary for the client to  <ins> generate a correct ClientHello pair.  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello. </ins> Upon receipt of a HelloRetryRequest, the client MUST first verify  <ins> that the selected_group field corresponds to a group which was </ins> provided in the "supported_groups" extension in the original  <ins> ClientHello.  It MUST then verify that the selected_group field does not correspond to a group which was provided in the "key_share" </ins> extension in the original ClientHello.  If either of these checks fails, then the client MUST abort the handshake with a fatal "handshake_failure" alert.  Clients SHOULD also abort with was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest).  <ins> Otherwise, the client MUST send a ClientHello with an updated KeyShare extension to the server.  The client MUST append a new KeyShareEntry for the group indicated in the selected_group field to the groups in its original KeyShare. </ins> Upon re-sending the ClientHello and receiving the server's ServerHello/KeyShare, the client MUST verify that the selected CipherSuite and NamedGroup match that supplied in the  <ins> HelloRetryRequest.  If either of these values differ, the client MUST abort the connection with a fatal "handshake_failure" alert. </ins> [[OPEN ISSUE: https://github.com/tlswg/tls13-spec/issues/104]]