Here's my attempt to quickly summarize the SG1 reaction after my
presentation.

Generally people seemed positively inclined. People liked the idea of
cutting back on the original TS. There weren't really any requests to put
specific pieces back.

Many people would like a mechanism that allows relatively low-level
portable access to HTM facilities. That generally seemed to be the highest
priority, and is consistent with what we've heard before.

Along the same lines, there was apprehension about not being able to get
feedback as to whether a transaction was actually executing in HTM. Several
people wanted a way to explicitly observe retries. I think especially the
HPC community needs something like that to diagnose the performance
problems that otherwise arise from a single global lock fallback.

There was concern that the RAII-based syntax allowed semi-nonsensical
constructs that would be hard to handle in the implementation. What happens
if the transaction_scope object is allocated somewhere other than on the
stack? How would you implement that? Even in cases in which it is owned by
a stack object, and thus does kind-of make sense, it seems problematic.

We did end up taking a quick poll about the two other options in SG1, and
it was 8 to 3 in favor of language syntax, with a significant number of
people not voting. I have little confidence that this would go the same way
in other groups. I may ask around to get some impression of how this might
go in EWG, which actually has more of a voice here.

There was some interesting discussion of co_await in transactions, and
"coroutines" in general. (C++ "coroutines" are very customizable, and may
not behave much like actual coroutines. So this question is probably a bit
more important and subtle than it seems at first glance.) We need to think
about this when drafting wording. I currently don't have good intuitions
about this.

The abuse of constexpr to define a minimal set of transaction-safe library
facilities was viewed with suspicion. It was pointed out that we would
probably need to list some exceptions in both directions. (Which I think is
OK, since I view this as an opportunistic specification mechanism.) I did
not hear an actual better alternative.