Once MongoDB timestamps are available to a single node there are cases where MongoDB will need to more carefully control which timestamp a checkpoint is created from. There are two cosntraints:

1) A checkpoint should not be created later than the common durable point across all nodes in a replica set.
2) On a secondary a checkpoint should not be created in the middle of a batch of oplog entries being applied.

Common durable point

This is a requirement because it is possible for it to be necessary to recover a node to the oldest durable point after a replication election. If a checkpoint has been taken that is newer than that point in time, it's no longer possible to recover to the necessary earlier point in time.

Secondary batch boundary

MongoDB optimizes applying the operations from the oplog, by sharing them amongst threads. There are certain ordering constraints that need to be adhered to so MongoDB can guarantee identical data is present on each node. This is handled by grouping the operations together into batches, and splitting the works amongst threads with care to ensure the ordering constraints are adhered to. There are some corner cases where a constraint may be temporarily violated during batch apply once global timestamps are being used. Guaranteeing that collection data isn't flushed avoids the constraint violation.