The config server can target an old shard primary (that has yet to find out that there is a new shard primary) for setShardVersion.

The old shard primary can step down while executing the setShardVersion and continue executing setShardVersion as a secondary as long as the stepdown occurs before here, because stepdown only kills operations that have taken a MODE_IX, MODE_S, or MODE_X lock. The old shard primary will then send _flushRoutingTableCacheUpdates to the new shard primary. If the new shard primary does not have an entry for the database in its CatalogCache, it will not schedule a collection refresh against the ShardServerCatalogCacheLoader, so the config.cache* entries for the dropped collection will not get deleted.

After the _flushRoutingTableCacheUpdates returns, the old shard primary (now secondary) will think its filtering table is up to date and will continue to accept reads for the dropped collection (even if the collection has been recreated elsewhere), which violates causal consistency.