Today, the local catalog implements some level of MVCC outside of the storage engine to detect conflicting DDL operations – e.g. concurrent creations of the same namespace. We should be able to revisit the durable catalog schema to push this responsibility back to the storage engine. This has many benefits: it simplifies the catalog, enables new use cases natively (e.g. support for prepare conflicts), allows for more efficient point-in-time lookups of durable catalog data, and is a step towards a durably consistent catalog between replicas.
 
Clustering the catalog with a cluster key on the "ns" field enables collection creation inside prepared transactions (SERVER-46105), which would otherwise require supporting prepared transactions and prepare conflicts above the storage engine.
An alternative approach would be a unique index on the "ns" field. This is more involved and would entail promoting the catalog to a regular collection, which is a direction we may want to take longer-term.