> So this basically means that replay throttling relies on the recipient being well-behaved in not acknowledging delivery twice

Right. We could track inside `ConfirmablePersistent` messages whether `confirm()` has already been called or not but I'd like to think a bit more if there's a better way to deal with it (and implement that in 2.4).

> can there be a race between ACK and NACK for the same message?

There are no explicit NACKs. There can be a race between an ACK and the re-delivery of the corresponding message, but this is what you probably mean, right? Because of this possible race, I'm using the `math.max()`.

> My intuition is that this might want to be changed to actually track which messages are outstanding instead of using a counter—unless I am missing something wrt. how to make that counter be reliable in all cases (which does mean that math.max() must be unnecessary, for example).

Yes, this would avoid divergence of the counter value and the number of outstanding messages. On the other hand, I'm not sure if this preciseness in limiting the number of outstanding messages is needed at all. In other words, the fuzziness of the existing algorithm/implementation might be good enough. Anyway, a change to your proposal might not be a big deal. I'll investigate that in 2.4.