Possible lost message over Failover/Failback using regular JMS Transactions

We found this issue over repeated tests on JBEAP-3998:

The Message Consumer has a list of delivered messages on both client and server.

When the message is received, the client will send an ACK to the server.

This ACK could ACK any previously received message.

Apparently that is making a previously received message to be acked and committed on the server as it was stored normally on the journal.

For some reason when using a LargeMessage over Paging and during a failback this list got out of sync and the client acknowledged more messages than it actually received, leading to a possible loss.

Notice that this doesn't affect MDBs since MDBs are always using individual ack, so scenarios where XA and MDBs are involved wouldn't be affected.

Also, this is not exclusive to replication, and it's not exclusive to Artemis. I can see the same issue happening on HornetQ and EAP6 as well.

Expected state: JMS standalone client can ACK messages in batches and no message is lost.
Actual state: When JMS standalone client ACK messages in batches some messages can be lost.
Customer impact: Usage of JMS standalone client with acking in batches can lead to lost messages.