Thank you for your report!
Let me clarify why a session is needed on the EVM side (solidity side of the protocol). Because the smart contract has hard limits on Merkle tree depth and on the number of slots behind each tree, the total number of entries is capped at 2048. This is what we call a session - that is all possible filled entries smart contract could handle in one tree.
That’s why, at any point in time, session T and all of {T-1, T-2, …, 0} have their own root hash that can be extracted with getRootHash on the smart contract side. The only session whose root hash keeps changing is the current one - in our example T - which we can describe as ongoing and changing.
The concept is to update the LoomState until validators observe that the session changed during the getRootHash call (take a look on return of it). That means all 2048 entries are filled with actual values and all of them are ready to be claimed.
So I do not understand how anyone could claim the same amount to the same receiver unless the root hashes match - which would effectively mean we have two identical Merkle trees representing exactly the same sequence of registered transactions across two different sessions. In any case, your report sounds promising. It would be great if you could elaborate and explain your idea in more depth, or perhaps the clarifications above will lead you to reconsider the abuse from a different angle.