We had logic to avoid re-wrapping previously migrated retryable writes noop in new noops. For example, if the previously migrated retryable writes noop the recipient fetches from the donor looks like {op: 'n', o2: <original_retryable_write_entry with ts 50>, ts: 100, ...}, the new noop the recipient writes would look like {op: 'n', o2: <original_retryable_write_entry with ts 50>, ts: xxx, ...} (where xxx is the timestamp at which the recipient writes the new noop).

After failovers, the recipient uses the ts in the o2 field of the last noop to determine where to resume applying/batching donor oplog entries.

Using the example above, if the recipient has processed a donor oplog at ts: 100, we should resume applying/batching from ts: 100. But because this doesn't preserve the processed donor optime in o2, the recipient would mistakenly resume from ts: 50 after failovers, which could result in processing the same retryable write twice or having two entries of the same statement in the oplog chain.