Currently, a shard key update that causes a document to move from one shard to another works as follows:

1. The client sends the update to some mongos.
2. The mongos forwards the update to the shard that owns the pre-update shard key value.
3. The shard throws WouldChangeOwningShard error.
4. If the update isn't running in a transaction, the mongos starts an internal transaction and retry to update to make sure that it still fails with a WouldChangeOwningShard error.
5. The mongos sends a delete the shard that owns the pre-update shard key value and an insert to the shard key that owns the post-update shard key.
6. The mongos commits the (internal) transaction.

Without additional handling, the additional WouldChangeOwningShard update and a delete may get sampled, and result in a sample population that is not representative of the user's workload. In addition, since the update is executed using a delete and an insert, it will show up in the OpObserver as an update so no diff will be sampled. So they will no get counted as a shard key update by the analyzeShardKey command.