A synchronization problem with an authorization dimension
A concurrent write conflict happens when two principals attempt to modify the same resource at nearly the same time, and something has to decide how the conflicting changes get resolved — whose edit takes precedence, whether both are merged automatically, or whether one is rejected outright and the writer told to retry. This is typically framed and solved as a purely technical synchronization problem, but the resolution rule chosen is doing something more: it's implicitly deciding whose intent wins when two otherwise equally authorized principals genuinely disagree about the same resource's correct state.
A resolution policy that silently favors whichever write happens to arrive at the server last, with no regard for who the principals actually are or the nature of what each was trying to do, can produce an outcome that looks and feels like an authorization failure to the person whose change was silently discarded — even though no individual access-control check anywhere in the system was actually wrong.
Deliberate conflict resolution as part of the authorization design
Treating conflict resolution as purely a synchronization-algorithm choice, made without regard for its authorization implications, risks a policy that technically works — data doesn't get corrupted, the system stays consistent — while still producing outcomes that undermine what authorized users reasonably expected their own permissions to mean. Designing the resolution rule deliberately, with its authorization consequences considered explicitly rather than left as a byproduct of whatever synchronization approach was simplest to implement, closes that gap.