The only issue that has come up is that LEWG would like us to present on August 17.

We will need a minor P2066 revision that briefly summarizes existing decisions. I can draft the additional text, and ask Jens to incorporate it. I don't think this requires group discussion.

My list of such decisions, copied from another thread:

1) Language, not library facility. Detailed discussion in P1875. (Like the current TS. The lambda-based alternative was not well-liked, and has issues with varargs access. The RAII variant raises weird semantics issues with transactions in the heap that nobody wanted to deal with.)
2) Leave a lot implementation-defined for the TS, to support experimentation. Focus on HTM or trivial global lock support, but allow more elaborate implementations. (Unlike the current TS.)
3) No support for explicitly declaring transaction-safety. (Unlike the current TS; major simplification.)
4) No escaping exceptions. (Unlike the current TS; major simplification.)
5) The "atomic do {...}" syntax. (Non-unanimous consensus in EWG. No better ideas. Mostly making it work without adding a keyword.)
6) [Recent change, but has been discussed in EWG] Allow malloc (and hence non-escaping exceptions, and much more of the standard library) inside transactions. (Also discussed in P1875, but more as an open issue.)

I think the main, and probably only, question for LEWG is whether the new list of facilities in 16.4.6.17 [atomic.use] is as good as we can make it without implementation experience.

Hans