Change:
NOT respond with a HelloRetryRequest.  Restarting the handshake from scratch, without a cookie, allows the client to recover from a situation where it obtained a cookie that cannot be verified by the <del> server.  As described in Section 4.1.4 of TLS13, clients SHOULD also abort the handshake with an "unexpected_message" alert in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). </del> <ins> server. As described in Section 4.1.4 of TLS13, clients MUST abort the handshake with an "unexpected_message" alert in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). </ins> 5.2.

Discussion:
This is an inconsistency between the TLS 1.3 text (which says "MUST" abort the handshake with an "unexpected_message" alert) and the text in this draft, which indicates a SHOULD.
I don't understand what this is trying to say. I think that it says that the client, having received a bad cookie will send its second ClientHello off into the void, only to have the handshake time out. Then, the client is expected to restart. This is probably right. The bad cookie indicates that something is badly wrong. Anything the server might send that would fix this wouldn't be authenticated and so might be exploited by an attack as a denial of service on the connection. However, I'm not sure if any client actually implements this restart.
Probably not, but I think this is just editorial. If you had some client-server type app then you might expect a retry (like Web clients do). Anyway, we shouldn't change the spec.
The text in DTLS 1.2 was a bit different, namely " If a server receives a ClientHello with an invalid cookie, it SHOULD treat it the same as a ClientHello with no cookie. This avoids race/deadlock conditions if the client somehow gets a bad cookie (e.g., because the server changes its cookie signing key). " I believe the DTLS 1.2 text was actually quite good. I suggest to re-use the DTLS 1.2 text again. The problem with the current text is that the Client will have to find out about the failed request via a timeout. While not common, it is not ideal either. If the current text does, however, prevent certain problems I am happy to leave it as is. I noticed that we incorrectly reference text from Section 4.1.4. of the TLS 1.3 RFC. In any case, I prepared a PR just in case: URL I also created a second PR to deal with the inconsistency with the TLS 1.3 spec, which I believe has to be addressed: URL
I don't believe that the bad cookie is a situation that needs to be handled in a different way than is described. Any server doing this uses a key identifier in its cookie. So, like ekr, I don't think that the design needs to be changed.

I would prefer to say that the ClientHello with a bad cookie is simply discarded (as Internet background noise, if you will). If the intent of the text (prior to as proposed) is to say that it's now the client's problem to fix, I agree with that. The question was about what the text meant, so an editorial fix would be fine. I would go so far as to say: