During FCV upgrade, DDL coordinators run authoritatively base on the AuthoritativeMetadataAccessLevel. Once the FCV is kUpgrading, new coordinators are started with an access level that causes them to persist authoritative information. Then, setFCV relies on a combination of coordinator draining and metadata cloning to ensure all collections have authoritative information persisted at the end of setFCV.

However, there is a bad interleaving in which stale information can persist due to a mix of AuthoritativeMetadataAccessLevels being possible during kUpgrading. The interleaving is:

1. On 8.0, start a dropCollection command. Instantiate the coordinator (metadata access level = none), but pause the execution before it acquires DDL locks
2. Start an FCV upgrade and reach kUpgrading
3. Shard the same collection which the dropCollection command is referencing (metadata access level = writes) and let it complete
4. Allow the dropCollection to proceed

Since the shardCollection was created authoritatively, it will persist authoritative metadata but the drop was issued non-authoritatively and thus will not clean up the authoritative information.