It has always had atomic operation per-document. So, if you're able to model transactional things in a single document, you've been able to use those semantics

It has always had atomic operation per-document. So, if you're able to model transactional things in a single document, you've been able to use those semantics. And as documents can be quite complex there are many use cases where it is possible and even desirable. However, MongoDB can not guarantee any operation that affects multiple documents will affect them all - if there was a failure after some documents were updated there is no rollback. However, between atomic single-document updates and the ease of implementing optimistic locking patterns, you still have options. Multi-document locking and transactions over a cluster of numerous shards is difficult. This is one reason why distributing documents is easier than rows of data. I'm not even sure they will ever have distributed transactions (using a 2-phase commit) because of how slow they are. However, single shard transactions should be easy to implement. But it will be use-case specific I imagine - you'd have to lock by shard-key to guarantee related documents are on the same shard I gather.