While sharding by a different shard key in general could require arbitrary amounts of data movement, sharding by a more-specific shard key doesn't have this problem. For example, a collection might initially be sharded by "region", then suddenly one region is huge, and the data must be resharded to split the regional chunks. Even though no data needs to be moved between shards, this isn't allowed.

If we were nicer, we could allow this by creating indices on each shard for the new shard key, then modifying the config db and appending criteria to the chunk bounds.