Should a client check the ACK token to match?

[Adirio]

A rare situation where a CoAP server is modifying the message token has been found. CoAPthon server is generating a message token when the request's token is empty. #16 has been opened to see if it is legal, but this behaviour has shown a CoAP client implementation (h5.coap) is checking that the token received matches the one sent.

When an empty-token message is sent from h5.coap clients to a CoAPthon server, the second is generating a token and thus the acknowledgement is being rejected, sending the original empty-token message again (and receiving a random-token ack again) until the maximum allowed number of retries is reached.

I'm quite sure that CoAPthon's behaviour of generating a token is not RFC compliant, but is h5.coap token matching check RFC compliant? I know for certain that most CoAP client implementations do not check this. The only reference I've found in the specification is in section 5.3.2:

In case a message carrying a response is unexpected (the client is not waiting for a response from the identified endpoint, at the endpoint addressed, and/or with the given token), the response is rejected (Sections 4.2 and 4.3).

The bolded section may be a definition of this situation thus meaning that the response is unexpected and therefore should be rejected. Is h5.coap, being the only implementation that takes this into consideration as far as I know, the only RFC compliant client implementation in this sense?