This was a mistake in the protocol v2 spec. The id is included in the re-enter so that the server can tell that this is an auto-re-enter (and so does not represent a channel in the presence data), and so is safe to idempotent-dedup if it's already in the presence set. But if the connectionId has changed then it's not the same member.
(Not actually that big a deal, since it's a different member then it won't be deduped anyway, the deduping logic only applies if the memberKey is already present. But still, it's wrong to have the same msgId)
This was a mistake in the protocol v2 spec. The id is included in the re-enter so that the server can tell that this is an auto-re-enter (and so does not represent a channel in the presence data), and so is safe to idempotent-dedup if it's already in the presence set. But if the connectionId has changed then it's not the same member.
(Not actually that big a deal, since it's a different member then it won't be deduped anyway, the deduping logic only applies if the memberKey is already present. But still, it's wrong to have the same msgId)