A primary running dropDatabase first majority commits dropCollection oplog entries and then writes a final dropDatabase oplog entry, with which the in-memory database is closed atomically. However, if replication rollback goes back to right before the dropDatabase and after the dropCollection(s), this leaves the node with no in-memory database state. Whereas nodes that were secondaries when the dropDatabase was running on the primary will still have the database open in-memory.

This sets the replica set up to allow a createCollection on a conflicting database on the primary, and then crash on oplog application on the secondaries with a DatabaseDifferCase error.

Potential solution: 

• Secondaries could check whether a database is empty before returning name conflict errors.
• SERVER-74703 should be re-examined to see whether or not it is simple to change something back to fix this new bug, without undoing the fix for the previous bug.