Diagnosing a Weak Memory Ordering Bug

Usually it is not. Acq rel only is useful when you can prove ordering of everything else can be nonsequential but still need internal (in-function) ordering guarantees. Generally you really have to run a miniature proof or exhaustive ordering analysis to be sure. It is useful when implementing nonserialized queues. (especially if you keep a Lamport timestamp or equivalent yourself for other reasons)

Release write/relaxed read is more useful, typically for work/cancel/finish flags that are spun on similarly to condition variables.

Load/acquire and store/release are sufficient pretty much when you're implementing a mutex-style operations, so you have a lock on a single value guarding vanilla memory operations that are unused outside of the mutexes. In pretty much any other scenario, (including, notably, most lock-free algorithms), it's best to start with sequential consistency and don't try to relax the memory unless you can prove correctness.

The actual bug in question used relaxed memory ordering, and the fix was to use acquire/release. Relaxed memory ordering really should be reserved for scenarios where you need atomicity but absolutely no synchronization (statistics counters are the only case that readily comes to mind).