There is one possible workaround, which I didn't see mentioned, and that would be to read the full (matched) document, create a targeted update to the array elements to change, and then updating the document only if no other changes have been made to the field (array) being updated.
Unless I'm missing something, this seems tantamount to read-update-write with two-phase commit, right? Maybe it's not technically the same, but it provides equal burden on the client to ensure the correctness of the transaction. And, just like in two-phase commit, a real-world application of this technique would require retry logic if the array actually had been updated in the meantime, resulting in yet another query (on top of the initial one that already feels superfluous for an update operation). And this becomes exponentially more problematic when updating highly contentious resources.
I would like to caution folks that if you have many documents with huge arrays, it's likely not an efficient schema design if you need to be querying and updating multiple array elements (especially if the array is indexed).
I of course would have to agree with this, but this is ultimately a problem class that is independent of dataset size.
Alright, obviously I'm frustrated. After 5 years and a hundred comments, I guess this just is what it is. And I honestly don't want to belabor a bunch of points about transactions and atomicity that I know you (Asya) understand at a much deeper level than me. It just seems like Mongo in general can get fuzzy on this topic. I.e., there's a lot of advice to put things in separate documents if you need certain update semantics, and to put them into the same document if you need certain transaction semantics, and then things get kind of hand wavy if you need both.
I get that no database can be "all things to all users", but this one is perplexing. We're not talking about actually changing transactional or atomicity semantics at all. We simply need a way to utilize those existing semantics via an extension of the query language. I'm not claiming it's trivial, but it doesn't seem intractable, either.