The need for a mechanism to ensure some operations are actually
performed, under whatever name we use, seems clear to me and has
been a recurring topic over the years. The work done by JF on
deprecating some uses of volatile also show (if we needed this to
be shown) that volatile lacked love... and, more formally, that
it was not sufficiently specified.

John Regehr has suggested in the past that, should be rethink
the volatile-related parts of the standard, one interesting avenue
could be to express volatile in terms of operations instead of
expressing them in terms of objects. If we took that path for
this mechanism (as was discussed in Cologne, from the paper
history; voting at 4 5 4 0 0 seems encouraging), we could start
to address the problems of adapting the abstract machine in terms
of a smaller subset of functions that impact the way we express
"as if", using some function that are not "as if" but have to be
taken literally by the compiler. This might localize the impact
of such changes to the sections where we discuss observable
behavior and fit in with std::observable.

Should we invest efforts in re-expressing aspects of the abstract
machine that discuss volatile in terms of volatile loads and