Unified tests of unacknowledged (w: 0) are inherently racy. Consider two contiguously executed tests of acknowledged writes to the same collection, and the order of operations is predictably

1. drop db.coll (start of first test)
2. create db.coll
3. insert into db.coll
4. drop db.coll (start of second test)
5. create db.coll
6. insert into db.coll

But if the first insert is unacknowledged, the order could be

1. drop db.coll (start of first test)
2. create db.coll
3. drop db.coll (start of second test)
4. insert into db.coll (leftover from first test!)
5. create db.coll
6. insert into db.coll

In which case the second create command will fail with a NamespaceExists error, because the collection drop from the second test ends up happening before the insert from the first test, so the collection is implicitly recreated by the insert.

This is not just a theoretical problem, as we're seeing this fairly regularly in the Java driver. The particular case is with the unified command monitoring tests. The A successful updateMany test fails with a NamespaceExists error, which is immediately preceded by the A successful unordered bulk write with an unacknowledged write concern test. Note that both tests use the same namespace (command-monitoring-tests.test).

The simplest workaround for this raciness is probably to just use a unique namespace for any tests of unacknowledged writes, but I'm open to other solutions.

Update

After discussion in the comments, a better approach is to force completion of the unacknowledged write by following it with an acknowledged operation, such as a find. Since connection pool size defaults to 1, the next operation will use the same connection, and won't complete until after completion of the unacknowledged write. And by using a find, we can assert this behavior by expecting the inserted documents from the unacknowledged write in the find command results.