In non-tx synchronous cache, locking on backup owners relies on having lock on primary owner held while the command is invoked on backup owner.

In non-tx asynchronous cache, the order in which updates are applied relies again on primary owner, but then the updates to backup owners are propagated as ordered.

When you mix it using FORCE_ASYNCHRONOUS flag, it's broken, e.g. in synchronous cache, you send the command to primary owner (that's fine), but then you replicate it to backups without the lock being held. That update can come in different order and even concurrently with synchronous update, and on backup owner the lock is not acquired. This can be problematic especially for conditional updates.