Tests have failed demonstrating that FIFO ordering is not ensured by the clist_mempool.
On instance 1, it was on a branch modifying the mempool but on instance 2 it was on a test that just limited the concurrency of the broadcastTX routine.
Resetting the clist next pointer when a block is decided could cause a transaction to be sent multiple times and filling the mempool could cause transactions to not be added to the pool, but these are not the cause here as the consensus was not playing a part in the test and the number of transactions was small.