I believe there are at least two paths that introduce mixed mode writes onto `local.system.replset`. Given this collection holds the replica set configuration, it's not surprising that the current timestamping semantics are lax. It's not clear to me if (after initialization) MDB should always be timestamping writes to the collection or never timestamping them.

• The first mixed-mode write is at initialization. I've been able to alleviate it with the following patch:

  diff --git a/src/mongo/db/repl/replication_coordinator_external_state_impl.cpp b/src/mongo/db/repl/replication_coordinator_external_state_impl.cpp
  index 45a54c4d35..e4914f7027 100644
  --- a/src/mongo/db/repl/replication_coordinator_external_state_impl.cpp
  +++ b/src/mongo/db/repl/replication_coordinator_external_state_impl.cpp
  @@ -457,11 +457,17 @@ Status ReplicationCoordinatorExternalStateImpl::initializeReplSetStorage(Operati
                                  // Permit writing to the oplog before we step up to primary.
                                  AllowNonLocalWritesBlock allowNonLocalWrites(opCtx);
                                  Lock::GlobalWrite globalWrite(opCtx);
  -                               WriteUnitOfWork wuow(opCtx);
  -                               Helpers::putSingleton(opCtx, configCollectionName, config);
  -                               const auto msgObj = BSON("msg" << kInitiatingSetMsg);
  -                               _service->getOpObserver()->onOpMessage(opCtx, msgObj);
  -                               wuow.commit();
  +                               {
  +                                   WriteUnitOfWork wuow(opCtx);
  +                                   Helpers::putSingleton(opCtx, configCollectionName, config);
  +                                   wuow.commit();
  +                               }
  +                               {
  +                                   WriteUnitOfWork wuow(opCtx);
  +                                   const auto msgObj = BSON("msg" << kInitiatingSetMsg);
  +                                   _service->getOpObserver()->onOpMessage(opCtx, msgObj);
  +                                   wuow.commit();
  +                               }
                              });
   
           // ReplSetTest assumes that immediately after the replSetInitiate command returns, it can
  

• I believe the other problematic write I've seen is correlated with a forced reconfig. I haven't taken the time to gather the details for that scenario.