This comes up in the context of thinking about how drop should work in tiered storage.  We want to ensure that if we drop a tiered table "abc", and there are still "abc" objects around in the cloud (in use by other nodes, backups, etc.), that we cannot create a new "abc" table.

Given that, it seems like a straightforward solution is to check the cloud bucket and see if there are any matching "abc".  Suppose our replica set as node1 and node2, we want to look for "node1-abc-" and "node2-abc-", and we want to ignore other nodes (first - how do we do that, do we have the complete list of replicas?).

Suppose we can do that. But then node3 joins our replica set, and in a past life (as part of a different rep set) it created "node3-abc-0007". That could be a problem if node3 happens to be primary and wants to make that object again.

That alone makes me wonder if our unique prefix name should be composed of a unique replica set name and a system id. Like prefix is "rep1-mach23-" .  Any objects created from a past life or another replica set should be left behind.  Another way to do it, is that a wholly new unique name is generated whenever a machine moves from one replica set to another.

All that said, this particular problem may not affect MongoDB, as unique GUIDs are used to "name" every table in WT.  Still, we may need to think about this more and come up with some recommendations for non MongoDB usage.