Shards that don't own any chunks are expected to retain some stale sharding metadata in the CSS (e.g., the shard key). This metadata gets sanitized when the shard receives a new chunk, so it's generally not a problem.

However, we discovered that unshardCollection can leave a shard's CSS pointing to the wrong UUID for a collection: this was not expected behavior.

We found this during making dropCollection commit to shard catalog, which targets all shards to clean up sharding metadata and expecting a UUID (the one from the global catalog). That revealed that unshardCollection is leaving stale UUIDs on shards that don't own (anymore) chunks.

Investigate whether this leftover stale UUID is acceptable. If it is, relax the tassert in dropCollection that currently expects every shard's UUID to match the config server's.