It is known that with sharded collections moveChunk and movePrimary might leave an empty collection in a shard that does not own data. This is fine considering the authoritative source of information is the config server, and is expected that queries rely on this information in order to target or filter data. This also holds true for unsplittable unsharded collections, considering they are mono chunk collections. Additionally, we need to ensure the primary database shard contains the local catalog information for the collection, so operations that rely on querying the primary shard work as expected, so in order to ensure this, SERVER-83925 was committed.

However, after SERVER-86309, we are untracking unsharded unsplittable collections during downgrade, which opens the possibility of leaving an unsharded collection metadata in a non primary shard, the following example is a plausible scenario for this metadata inconsistency:

1. In v8.0 an unsplittable collection is created in shard0, considering the database primary shard of the collection is also shard0
2. A move primary happens, changing the database primary shard to shard1, this would leave the unsplittable collection in shard0, but it will create the local metadata in shard1
3. Another move primary happens, changing the database primary shard back to shard0 but leaving the local metadata in shard1
4. A downgrade happens, setting the FCV to 7.0 and untracking the collection, leaving the local metadata in both shards, when it should only be in shard0

You can find a reproducible attached. We can solve this issue by either broadcasting a drop collection on the untrack collection coordinator on all the non primary shards (like drop collection does after the commit), or by cleaning up the origin shard in movePrimary.