Part of the issue in SERVER-94559 was that, by performing a non-metadata delete that replaces an existing bucket document with a new one, we were able to update the control.min.time of a bucket which would be the shard key for a time-series collection sharded on time.

In other words, we were able to change the shard key without going through the usual sharding machinery for doing so, which would have properly moved the chunk that a bucket belonged to. This ticket would investigate whether it's possible to create some sort of invariant on when this is done to prevent future documents from being orphaned in this manner.