This is similar to SERVER-120623 where the ordering of writes change because we assign new timestamps at commit for batched writes. This is caused by enabling batched writes by default in DSC.

Oplog slots are reserved for retryableFindAndModify with the later timestamp (T) expected to be the oplog timestamp. However with batched writes, the oplog timestamp is actually assigned at commit time and therefore will at least be T+1. However, other operations can also reserve timestamps between reserving T-1 and T such that commit time is >T+1.

For retryable find and modify, we need to definitively know what timestamp to find the pre-image. One solution might be to reserve the opTime for the pre-image closer to where we're reserving the commit timestamp. Or we may also try to use the timestamp we already reserved for the operation as the applyOps timestamp.

This issue actually seems more like SERVER-119061 where because we're reserving timestamps earlier in the operation, that is the timestamp also used for the actual find and modify write. When we commit, we reserve a new timestamp for the oplog entry and that is what timestamp for the write when replicated however on the primary, the oplog timestamp will not reflect when the actual write occurred. If we avoid reserving this timestamp earlier and only do the storage write at the timestamp when we commit (T), the preimage should be found at T-1.