The top-chunk auto-split optimization does not consult the global chunk distribution state and might cause chunks to move unnecessarily.

Consider the case where there are 4 shards with the following assignment of chunks:

Shard1 - 100
Shard2 - 10
Shard3 - 0
Shard4 - 0

If inserts are happening to a chunk on shard 2 and these trigger top-chunk auto-split with suggested move, a chunk from shard 2 will be moved off to 3 or 4, even though this is completely unnecessary given the overall distribution.

The problem is slightly exacerbated in 3.4 with the support for parallel migrations, because there is higher chance that in this case the second migration will actually proceed, versus in prior versions where the migration will most likely fail due to the restriction of single migration per collection.