The current `modifyMVar`, though "exception safe", is not "atomic" in the same way that the proposed `atomicModifyMVar` would be. Unless I misunderstand, during the execution of `modifyMVar`'s second argument, the mvar is empty and could be filled by some other thread. With `atomicModifyMVar`, the contents of the mvar are changed atomically, based on the given (pure) function; no other thread can intervene.
This is true, but I've never come across an application for which atomicModifyMVar is essential; the two main idioms for using MVars that I know of are - each thread does take followed by put in strict sequence - the MVar is used as a 1-place channel, with some threads doing put and some (usually one) doing take. So the fact that modifyMVar isn't atomic in the presence of another thread doing a concurrent put doesn't usually matter, because there are no such threads. However, I agree that atomicModifyMVar does provide functionality which doesn't currently exist. Cheers, Simon