The rules in 7252 about separate responses are that once an empty ACK goes out, later duplicates are to be ACKed again, "and any response MUST be sent as a separate response."
Detecting this requires collating different requests into state held on the server side. While some such state needs to be around anyway while a CON response is being sent, CoAP largely tries to free the server from obligations to keep such state longer by the message deduplication relaxation rules.
The concrete rule on separate ACKs forces a strictly compliant server to keep that information around, whereas it should be perfectly safe just to respond with a response-carrying ACK, and the client accepts whatever comes first.
A relaxed rule might be (emphasis indicating changed part):
When the server chooses to use a separate response, it sends the
Acknowledgement to the Confirmable request as an Empty message. Once
the server sends back an Empty Acknowledgement, it MUST transmit the
separate response completely. If a retransmitted request is
received (perhaps because the original Acknowledgement was delayed),
an empty acknowledgement or a piggybacked response may be sent,
but neither frees the server from its obligation to see any CON response
it started sending to completion (by an ACK, an RST or a retransmission timeout).
An explanatory remark could point out that servers that can forego request deduplication can thus just answer without doing the matching, and that for short responses piggybacked ACKs are preferable (because they allow the client to obtain the result sooner than at the next retransmission) whereas for long responses empty ACKs are preferable as they avoid sending the payload more often than necessary.
The change should be purely beneficial to the overall performance: the client has a chance of receiving the response earlier, has one fewer error path to check when it's feeling strict, and the only stalling condition (which is that the client only sees the empty ACK but the server drops the CON retransmission in favor of the piggybacked response, causing both parties to wait for the other) is explicitly ruled out by keeping the server's obligation to retransmit.
(For cases where the server sends a separate NON response, which I have yet to see in the wild, it allows one more kind of recovery if the server chooses to send the full response again).
The rules in 7252 about separate responses are that once an empty ACK goes out, later duplicates are to be ACKed again, "and any response MUST be sent as a separate response."
Detecting this requires collating different requests into state held on the server side. While some such state needs to be around anyway while a CON response is being sent, CoAP largely tries to free the server from obligations to keep such state longer by the message deduplication relaxation rules.
The concrete rule on separate ACKs forces a strictly compliant server to keep that information around, whereas it should be perfectly safe just to respond with a response-carrying ACK, and the client accepts whatever comes first.
A relaxed rule might be (emphasis indicating changed part):
An explanatory remark could point out that servers that can forego request deduplication can thus just answer without doing the matching, and that for short responses piggybacked ACKs are preferable (because they allow the client to obtain the result sooner than at the next retransmission) whereas for long responses empty ACKs are preferable as they avoid sending the payload more often than necessary.
The change should be purely beneficial to the overall performance: the client has a chance of receiving the response earlier, has one fewer error path to check when it's feeling strict, and the only stalling condition (which is that the client only sees the empty ACK but the server drops the CON retransmission in favor of the piggybacked response, causing both parties to wait for the other) is explicitly ruled out by keeping the server's obligation to retransmit.
(For cases where the server sends a separate NON response, which I have yet to see in the wild, it allows one more kind of recovery if the server chooses to send the full response again).