After a (long overdue) complete read of both r0 and r4 of p1152 i have
come to a few conclusions:

 1. While the motivation in r0 is quite thorough, it fails to convey
the dangers of using the compound volatile operations in higher level
highly threaded code that was alluded to in tonight's meeting.
    If anyone could enlighten me further in this regard I'd be much obliged.
 2. The changes that Wouter and others (myself included) found
frightening were mostly neglected in R0: "This is a departure from C
which breaks source compatibility (once removed), but maintains ABI
compatibility."
    And even though the committee was heard on the question, the
question was before SG1 and EWG ( from r0 -> r1 changelog), not
necessarily parts of the committee that are affected by the proposed
changes (compound operations).
 3. The only change to the r4 paper that I can see would be necessary
is in 3.7 item 9 where "op=" is discussed.

I would posit that, put before SG14 the vote on "Deprecate volatile
compound operations (including ++ and --) on scalar types (arithmetic,
pointer, enumeration)." would have been a very different one and we
might even revisit this at the next embedded themed SG14 meeting.

The concerns regarding incorrect usage of the comppound operations is
not as bad as they are made out to. It is even there in the standard
right next to it:
"The behavior of an expression of the form E1 op= E2 is equivalent to
E1 = E1 op E2 except that E1 is evaluated only once"
While the wording might be a bit clearer this explicitly states that
it is the same. Examples regarding tearing in the parts of volatile
that have been retained are also mentioned in the paper and as such I
do not see the reason why this usage of volatile should be any more
onerous.

Regarding the concern of breaking functioning code expressed as code
that must operate on variables that must be declared volatile that
also has a controlled application of the compound operation, I find
that it has not been very well examined and I am perplexed that the
committee would break codebases for such a large part of the C++
community.

The paper even acknowledges the quite early retirement of volatile,
with the, in my eyes, incorrect assumption:
"Now that codebases use atomic and have moved away from erroneous
volatile, we believe deprecation is warranted. In other words, what
would have been a disastrous breaking change for C++11 is merely good
house-cleaning for C++20." (from r0)

Finally, on a more introspective note, this leaves me with some doubts
regarding what we are doing here.
This paper has its r0 date in 2018. I have been following this group
since at least then and cannot remember it ever being mentioned before
being part of the standard.
If the purpose of this group is to be an outreach group and get the
opinions of people who don't regularly attend standards meetings, then
this paper becoming standard marks a failure on this point to me.
We need to do better and I would like to hear from the rest of the
group if you have any idea as to how.

Before going too much into discussions on this, please read the two
paper versions (that are actually different papers), they are well
written and relatively short and having read through them will give
you a better understanding of what is being discussed and will prevent
others from having to tell you what is in them.

Best Regards
Paul M. Bendixen

-- 
• − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − −
•− •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//