SERVER-84723 didn't fully fix the reported bug when resharding is involved – there's still a small window of time where anomalies can occur.
Resharding first commits on the configsvr (which produces the new collection 'timestamp') and later commits on the shards (renames the resharding temporary collections to the original namespace). Transactions that logically execute at a timestamp in between the two steps above will match post-resharding sharding metadata with pre-resharding data. SERVER-84723 didn't fully fix this because it relies on the new collection 'timestamp' to guarantee that any operation that executes at a later logical timestamp is safe – this isn't true considering the way resharding commits.

On v8.0, this affects moveCollection too.