Hello Roger,
That's super helpful! I was only thinking about retransmission in the broker... I guess what the python client does matters also, but the patch I put into the python client just makes automatic sending of ack's by the library optional, adding an ack() function to let the application send them on its own.
Because in the scheme described, A Standards compliant client will never resend a message unless there is a re-connect, that would be awful if using a lossy network... so I guess they are depending on TCP underneath to deal with lossy networks... yeah that sounds like a reasonable/smart choice, so the MQTTv5 retransmits are only for cases where the connection actually broke... OK that makes it efficient in high queue cases.
OK so with v5, doing the acknowledgements a little later is no problem at all? So then my patch should be harmless in v5, and only change things in v3.x for cases of slight queuing, where it will make things slightly worse.
If someone deals with the current pull request, I can work on fixing retransmission for v5 as Roger prescribes in a future patch.