It is not valid to call setLastOpToSystemLastOpTime() and then wait for majority writeConcern to ensure that any data read was majority committed. The reason is that writes update the lastApplied in an on-commit hook after the data changes are made. Consider the following scenario. Originally the lastApplied is time 1. Operation A updates the document {_id: 0} to have a=5 and writes an oplog entry with time 2. Operation B reads the document {_id: 0, a: 5}.  Operation B calls setLastOpToSystemLastOpTime() and gets the lastApplied time as time 1. Then the on-commit hook for Operation A updates the lastApplied to time 2. Operation B will wait for the majority commit point to reach time 1, which does not guarantee that the data that it read was majority committed.

Any callers of setLastOpToSystemLastOpTime() that use it to ensure data read was majority committed are suspect. This excludes reading transaction state in transaction operations, since they are serialized by the session checkout mechanism, so a new transaction operation cannot start until the on-commit hooks have finished for the previous operation.