Normally, test/format may have multiple operations in a single transaction.  Predictable replay was added to format in WT-9915, but multiple ops in a transaction was not implemented.  It seems possible to do, and probably not too complex, so worth considering.

Currently, for predictable replay in format, we have the concept of lanes, which stripes the set of timestamps (and keys being operated on for that timestamp) into N lanes.  Since only one thread can "own" a lane at once, this prevents a key from being operated upon simultaneously by multiple threads.

One approach to solving this ticket, would allow multiple operations, but only in the same lane.  This is not as restrictive as it may seem.  The same lane can handle operations to many keys in a table (1/Nth of the keyspace) and multiple tables.  The advantage is that we still use the same idea that a thread owns a single lane nobody else can touch the keys in that lane.

In test/format, when a thread gets to the "top of the loop", it gets the next timestamp to work on, and uses that to seed its RNG, and then we start a transaction. So I think the extra work is that when we begin the transaction, we use the data RNG to decide how many operations should be in the transaction and stash that in the TINFO struct.  Then we use the RNG to determine the first operation, and do that normally.  When we would normally commit, we look to see if there are more operations to do, if so, we skip the commit. When we get to the top of the loop again, we look to see if we have more operations to do.  If so, we know not to reseed the RNG, and not to start another transaction.  I don't think there's a whole lot else to do and it doesn't seem that complex.  Hard to really know without diving in.