SERVER-47205 describes why dropping snapshots after reconfig is ineffectual.

The consequence is that until an operation is committed in the new config, majority reads will read at a timestamp that was committed under the old config. Writes are affected more narrowly. Any new operation that performs writes will wait to be committed under the new config. A write operation that does not write data (a noop write) will wait for the system last optime to be committed. If the system last optime is from before the reconfig, then the write is acknowledged when the data that was read is committed under the old config. This can only happen in a narrow interval, since we write a noop oplog entry immediately after reconfig. In particular, operations on the same client thread as the reconfig will not be affected. However, it’s possible for a different thread to read the new config, then do a noop write with majority writeConcern, and have the write be acknowledged under the old config.

Majority write acknowledgment after force reconfig is incorrect until the _currentCommittedSnapshot in the old config becomes majority-committed in the new config. Majority write acknowledgment after a safe reconfig that changes writeConcernMajorityJournalDefault is incorrect until the _currentCommitedSnapshot in the old config becomes durable on a majority.