SERVER-97831 provided a targeted effective fix for the issue explained in its description.

However, it is still unclear why the reproducible proved that the bug could only affect collections that existed in the past before being dropped via dropDatabase.

Purpose of this ticket is to investigate whether there was some deeper issue related with some stale in-memory cache.

After locally reverting SERVER-97831, the issue can be reproduced by executing the following steps:

1. db.runCommand({create:'a', writeConcern:{w:'majority', wtimeout:300}});
2. db.dropDatabase();
3. db.runCommand({create:'b', writeConcern:{w:'majority', wtimeout:300}}); // Implicitly re-create the db by creating another collection
4. Block secondaries (e.g. stop replication on secondaries via fsync lock)
5. db.runCommand({create:'a', writeConcern:{w:'majority', wtimeout:300}}); // This should fail with a write concern error but succeeds