During a mixed-FCV window in a setFCV upgrade (8.X → 9.0), a shard can be left with a stale authoritative collection entry for a namespace whose UUID has already changed, causing subsequent authoritative DDL operations on that namespace to get stuck with an InvalidUUID mismatch.

Root cause:

Collection sharding metadata entries are normally cleared on all shards when a collection is dropped or renamed. However, if a non-authoritative rename/drop (FCV=8.X) occurs on a shard that still holds a leftover authoritative collection entry (e.g. left behind after an authoritative movePrimary), that entry is not cleared, since the non-authoritative path doesn't know to clean it up.

When the shard later becomes fully authoritative (FCV=9.0) and recovers its on-disk metadata into the CSR, it recovers this stale entry impacting in different ways (checkMetadataConsistency inconsistency, InvalidUUID error at some DDLs, etc.).