Major WD11, lines 255-297 contain a non-normative comment that says
"If 1, the recipient might have previously received the message, it shuld not treat this flag as an indication that it has previously received the MQTT Command message and should not use the DUP flag alone to guarantee to its application that a duplicate message is being redelivered to its application interface."
There is a typo "shuld", and the use of two different terms "message and MQTT Command message" which I think mean the same thing. However we haven't really defined the role of recipient or "its application" and in addition it made me notice that we don't say anything normatively about how the server should handle an incoming Control Packet that contains the DUP flag.
I think what the current non-normative words are trying to say is that when a recipient receives a Control Packet with the DUP flag set to 1, it should not assume that it has previously seen that Control Packet, just because the DUP flag is set. It might not have received the original copy at all, or it might have received it but had failed before it had managed to do much processing of the message.
Do we need further normative words?
1. The specification should not dictate how a receiving client library handles its relationship with its application, so no more words are needed here. A client library might choose to dedup its incoming PUBLISH messages, or might simply hand them off to the application with the DUP flag set.
2. Similarly we should not say exactly how the server handles incoming PUBLISH messages which have the DUP flag set to 1. However if it does decide to deliver the message to one or more subscribers, how does it set the DUP flag in those messages? Does it set it to 0 for the first attempt, or does it set it to 1 on all attempts? I think that's something which should be normatively specified.
3. Are there any special semantics relating to a SUBSCRIBE with DUP = 1?