The establishConsistentCollection helper has a race condition during parallel collection creation when child write units of work (WUOWs) are involved and fails to read it's own writes.

Context

After a child WUOW is committed, an operation can only find a collection via establishConsistentCollection  by looking into the in-memory catalog (child WUOW do not actually commit in the durable catalog).

That means that a child WUOW commit is equivalent to add to UncommittedCatalogUpdates (thread-local), while a concurrent collection creation that is not a child transaction will add the change to the list of pendingCommits (shared) during its commit phase and later write in the durable catalog.
When the establishConsistentCollection finds the entry in pendingCommits , it assumes the namespace must be in the durable catalog and that's requires to open a collection (i.e create a temporary collection object in the snapshot)
If a collection is found in the pendingCommits but not in the durable catalog, we assume the collection is being dropped.

Problem
2 creations:

• create 1 (part of a child transaction)
• create 2 (part of a top level transaction)

Run concurrently. 

create 2 might be already in the commit phase, have the entry in the pendingCommits but not in the durable catalog.
create 1 has already committed and runs an establishConsistentCollection (subsequent to a creation) and expects to see the collection.
The establishConsistentCollection will find the collection in the list of pendingCommits (due to create 2), assume it must be in the durable catalog, and believe the collection is dropped. 

Solution

The fix is to update establishConsistentCollection to also search UncommittedCatalogUpdates when checking if it needs to open a collection and proceed with lookup in case it's found. 
In general, a child transaction should never look into the pending commits, because any catalog change will only stay in-memory until the parent commits.

—

As part of this ticket please re-introduce the changes that were reverted in SERVER-109551