The create collection cmd:

1. attempts to create the collection and if the collection already exists with the same options it raise a NamespaceExists error
2. It then catches the NamespaceExists and check if the already existing collection have the same options. If the options match it will swallow the error and return OK

Between 1. and 2. the command does not hold any lock for the collection, thus If a drop manage to drop the collection after 1., the create command will not find the collection in 2. and thus it will simply propagate the NamespaceExists error to the driver.
This is wrong in fact the only correct execution of this 2 concurrent DDL are the following:

• drop commit before create -> create manage to re-create collection and returns OK
• create commit before drop -> it finds the collection already existing and with the same options and returns OK

Thus raising NamespaceExists in this scenario is incorrect and break the idempotency guarantees of create commnad.

NOTE: the bug only affect replicasets because in sharded cluster the create and the drop and serialized through the collection DDL lock