I apologize for merging the problems of dropCollection and dropDatabase needing timestamps into the same ticket. They're highly related and how one problem is solved likely influences how the other is solved.

In 3.6, dropping a collection does the following:

1. Rename the collection to a special name in the same database
2. Replicate the collection drop to the oplog with OpTime T. The write that represents the rename to the catalog is assigned this timestamp.
3. Asynchronously, a reaper task will be scheduled to physically drop the collection when T is majority committed. This write that represents dropping the collection from the catalog is not timestamped.

In 3.6, dropping a database works as follows:

1. Loop through all collections in the database:
   1. Drop (rename) the collection.
   2. Replicate this drop command.
2. Wait for all collection drops to become majority committed.
3. Finish dropping the database which includes calling StorageEngine::dropDatabase

This is where dropDatabase gets fun. After the command thread wakes up after waiting for the collection drops to become majority committed, it actually races the reaper in dropping the collections. The drops in the linked block are also not performed with a timestamp. As documented by the KVStorageEngine, this dropDatabase method is not called from within the same WriteUnitOfWork as the logOp.