This isn't a new inconsistency for indexes on a sharded collection but a new way for an inconsistency to manifest. For comparison, the createIndexes command broadcasted by mongos to all shards which own a chunk for the sharded collection can fail on one shard and succeed on another (same for the dropIndexes command). The main consequence is it can lead to chunk migrations failing with a DuplicateKey exception because shards are enforcing different index constraints from each other.

Let's say there is a collection sharded on {x: 1} which lives on 2 shards and has a non-unique index {x: 1, y: 1}.

1. The collMod command is run with {prepareUnique: true} for the {x: 1, y: 1} index to start preventing new duplicate (x, y) pairs from being inserted or updated. This step succeeds on both shards.
2. The collMod command is run with {unique: true} for the {x: 1, y: 1} index to verify there are no existing duplicate (x, y) pairs. This step succeeds on one of the shards and fails on the other shard.

A chunk migration between the 2 shards may fail with a DuplicateKey error due to the (x, y) pairs not being globally unique across all shards. Removing the duplicates and retrying the collMod command is run with {unique: true} may not be practical. However the cluster operator is also left without a means of converting the {x: 1, y: 1} index back to being a non-unique index.