No, even when you set the QoS to 2, "ExactlyOnce", you may still hit edge cases where you loose data, without knowing it, especially on enterprise networks, or if there is an high throughtput.

That when you use QoS 2 "ExactlyOnce" (or 1), you will never loose a message.

The issues I spotted are how the protocol is implemented, not how the packets are stored.

It will work fine for your small scale IoT, but when they said "for IoT" they never meant it for high scale.

Yes, but no. If your protocol or your implementations have holes, you may loose messages because of that, and in a lot of applications, it's unacceptable to have the transport protocol dropping packets.

To never loose a packet on QoS 1/2.

The Packet ID logic is not enough restricted.

For exemple, the emitter is not restricted in the ID it should use for it's packet, it can be any unsigned 16 bit number.

In contrast, a lot of protocol the ID must be incremental, and the receiver can detect that a package is missing (which result in smaller network overhead, the client can ack, or re-ask for a dropped packet, which result in a single roundtrip when there is no issue, instead of having the double round trip that mqtt have). It means that, the receiver can't know if it missed a packet. Because you don't have to waits for the acks to propagate the message, it mean the message delivering is unordoned. It also mean that if the same message keep dropping, the protocol should continue to work. Now if you implemented your mqtt with an i++, this where you can start to have dataloss, because now that you sent 65k messages you finished you start to need actually free packet id.

And it cause a lot more issues that what I said there, that I hope I covered every case in my implementation: https://github.com/signature-opensource/CK-MQTT/blob/develop...

Then, this is just the PacketID Logic. MQTT 3 doesn't do enough things, while MQTT5 do too much things. MQTT 3 Have design issues which MQTT 5 acknowledged it, and tried to fix it with duck tapes. One issue for exemple is the credentials being sent after the last will packet, which lead to a huge DOS issue, because now an attacker can attack you with your maximum last will packet, that you will want to save to disk, then wait to timeout without ever sending credentials. MQTT 5 is not really a breaking change as this behavior still exist, but you can enforce a credentials packet for the connexion.

All this highlight that MQTT could be a far smaller, faster, simpler protocol if correctly done (and a protocol like this probably exist, I didn't looked at a lot of popular protocols for now, only a dozen of hardware custom ones).

If I knew all the above before starting to implement my MQTT client, I would had want with another protocol.