When an unsharded database is re-created after a "dropDatabase" command has been used, and it happens to be located on a different shard as a result, only the initiating mongos of the drop observes the subsequent re-creation - all others continue to route as they did before.

This leads to the same problems observed with movePrimary, other mongos will populate & query, what is now, the wrong shard.

This is essentially a different way to invoke the movePrimary command, with similar results, and thus requires that all other mongos be restarted or flushed to function correctly.

This seems like an unreasonable requirement for dropDatabase to be burdened with, given it is considerably more common than movePrimary.