For Authoritative Shards, we rely on drop DDLs (e.g. drop, rename with dropTarget...) to clean up stale collection entries in the authoritative catalog (config.shard.catalog.collections). This is only done once those DDLs are authoritative.

For this to work during FCV upgrade however, we assume that once a DDL is authoritative, all following DDLs are also authoritative (e.g. the interleaving of DDLs is ...nonauthoritative-nonauthoritative-nonauthoritative-authoritative-authoritative-authoritative...).

However this is not necessarily the case because the decision on the authoritativeness and the execution order are decided at two different points:

• The authoritativeness is decided when the coordinator document is created.
• The execution order is decided by whoever takes the DDL lock first.

So it's possible to have an interleaving of DDLs like ...nonauthoritative-nonauthoritative-authoritative-nonauthoritative-authoritative-authoritative...).

This can cause us to leave a stale authoritative sharding metadata by the same mechanism as SERVER-131541 (see attached repro).