Hey, just noticed this and wanted other people to check my thought process.

I don't believe that the current proposed wording for p3181r1 (Atomic stores and object lifetimes) actually entirely solves the issue it's trying to fix?

For convenience, the proposed fixed wording for [basic.life]p1 is reproduced:
> In this subclause, “before” and “after” refer to the “happens before” relation (6.10.2), with the following relaxation: An atomic store X to an object is also considered to be “before” the end of an object's lifetime, if a load both observes the value stored by X and happens-before the end of the object’s lifetime. [ Note: This allows a memory_order_relaxed store, possibly preceded by an atomic_thread_fence() to inform another thread that an object is ready for deletion. --end note ]

The paper mentions atomic refcounts as an example of what is trying to be fixed and I don't believe this wording actually fixes them in general. Consider the following program:

```
atomic_int* ref = new atomic_int(2);
void thread1()
{
    ref->fetch_sub(1, memory_order_relaxed);
}
void thread2()
{
    ref->fetch_sub(1, memory_order_relaxed);
}
void thread3()
{
    //reads 0
    if (ref->load(memory_order_acquire) == 0)
        delete ref;
}
```

In this example I don't believe that the wording actually prevents undefined behaviour from happening - the read that happens-before the end of the object's lifetime definitely observes the value of *one* of the fetch_subs, but I wouldn't consider that it observes the value of the other (certainly, I don't think it's possible that both instances of fetch_sub could store the value of 0, which is what the read observes).

I think the intention of the paper is that they actually should be requiring that X is coherence-ordered before ([atomics.order]p3) the load rather than having the load merely observe the specific value written by X, which I think would cover the example above, unless anyone sees any issues with that too?