This is currently enforced through the setShardVersion command. Some of the issues:

1. There is currently no single authoritative source of truth. The configdb string is passed to the mongod through the setShardVersion command and the first one to succeed wins for that shard. So it is possible for shards within the same cluster to have different configdb string.
2. The reliance on setShardVersion means that mongos will not detect if a different configdb string exists in the server if it never performed any operation on versioned namespaces. Note: majority of the writes in the sharding internals to the config are unversioned.

Mongos also sends the full config string for metadata changing commands performed by shards like moveChunk, splitChunk and mergeChunk. However, these are currently only used for initializing the sharding state in the shard and is never used for checking consistency if already initialized.