The issue is found through  aggregation_unsplittable_collections_on_random_shard_passthrough_with_config_transitions.yml suite with createUnshardedCollectionRandomizeDataShard failpoint.

More details can be found in https://jira.mongodb.org/browse/SERVER-98123

When a config shard is migrated to a dedicated server via 
transitionFromDedicatedConfigServer admin command, it possible that after the process started, the config shard will be still available in the shard registry and can be received via shardRegistry->getAllShardIds(opCtx).
It's possible to send a createCollection request to this "inProgress" shard and there could be a race, when this collection will be created after it becomes a dedicated server.
 
In this case the will be a dedicated config server with a customer collection.
Another problem, that this dedicated server cannot be migrated back to the config shard, as there will be a conflict, that the same database exists already on other shards.

Possible areas to investigate:

• ShardRegistry is not updated after the transition process is started
• When a transition finished, any customer command like createCollection has to be not allowed.