Creating/dropping WiredTiger tables are not "transactionable" operations, they take effect immediately. MongoDB maps collections (and indexes) to WiredTiger tables with the following algorithm:

Create:

1. Create the WiredTiger table.
2. Create the collection document in the `_mdb_catalog` referencing the table.

Drop:

1. Remove the collection document from the `_mdb_catalog`.
2. Remove the WiredTiger table.

If a crash happens, there are three cases to consider:

1. Both the collection document and the table exist. Everything is fine.
2. The collection document is missing, but the table exists. It's legal to drop the table.
3. The collection document exists, but the table is missing. The algorithm forbids this state.

However, a combination of stable checkpoints and turning off journaling for the `_mdb_catalog` changes this expectation. When a node crashes, the data on disk may still contain the `_mdb_catalog` entry for a dropped collection, but the table will be missing.

This ticket is to coerce the storage engine into believing this is a legal state, specifically in the case of crash recovery. In this mode, the storage engine will drop collections documents from the `_mdb_catalog` when their corresponding table is found not to exist. There's a followup ticket, to be written, where the goal is to make storage engine drops safe in this regard in a more robust way.