When enableMajorityReadConcern:false, we disable journaling of replicated tables and use stable checkpoints and the oplog for crash recovery. Stable checkpoints in this case are not guaranteed to be behind the majority commit point, so we still use the rollbackViaRefetch algorithm. Under this configuration, it is possible for us to create a stable checkpoint whose collection data has two documents with the same _id. Consider the following behavior. Assume all operations are done on the same collection, and that no checkpoints are taken other than the one explicitly forced after rollback:

1. Insert a document {_id:1} at timestamp T=1, with RecordId=1. Let this write majority commit.
2. Delete document {_id:1} at timestamp T=2 and assume this write doesn't majority commit.
3. Enter rollback, where the delete operation at T=2 is the only op necessary to roll back.
4. To undo the delete operation, rollback refetches the document and inserts a new document {_id:1} with RecordId=2
5. Complete rollback and set the stable timestamp to T=1, the rollback common point.
6. Force a new stable checkpoint to be taken. This checkpoint, call it C1, is taken at timestamp T=1.
7. Shut down uncleanly.
8. Start up and recover from the most recent stable checkpoint, C1.

Because the checkpoint was taken at T=1, it does not include the delete at timestamp 2, so the storage engine includes the document at RecordId(1) in the checkpoint. This document is a duplicate of the document at RecordId(2), so when we crash and recover from this checkpoint, we will have two documents with the same _id in the collection.