The introduction of WriteConflictExceptions adds another lock-reacquistion path for certain storage engines. Because sharding and replication code need to recheck invariants on most lock reacquisition, this increases the number of places that need to be audited for correct behavior on reacquiring the lock. WriteConflictExceptions also break the executor model, in that successfully running an update/delete query now requires a retry loop which is easy to forget.

Some sort of encapsulation of the invariants that need to be checked every time locks are reacquired would make it possible to generically run an executor with retry whether the lock reacquisition was due to old-style yielding or new-style WriteConflictException retries.