Hey Ted,

Since you're new to the process, the paper will almost certainly not
go to LEWG directly. It will probably have to be seen by LEWGI first,
and since it has to do with concurrency, by SG1. You may as well add
SG1 to the paper audience right away, at least.

I think the paper and its design makes sense. I find the alternative
designs discussion to be a bit shallow though. If the interface was
container-based, you could make it non-owning such as by taking
std::span, and I doubt this would perform much worse than the variadic
version you have.

The motivation of the paper is a bit unclear to me. It's true on paper
that std::scoped_lock cannot be moved, so it "loses flexibility", but
how often is that actually an issue? Needing a multi-mutex lock with
ownership transfer seems like an incredibly niche problem. Are there
practical real-world examples where people need this feature? If so,
that should be part of the motivation in the paper.

As for the wording, the latest working draft is N5014, and the paper
should be based on that, ideally. You're wasting your time by
including the section numbers in the headings; those change all the
time anyway. Here are some wording issues to fix:

1. Are you suggesting adding a second introductory paragraph after
[thread.mutex.general] paragraph 1? We already have one, so this seems
redundant.

2. "An object of type unique_multilock" is a category error because
unique_multilock is not a type, but a class template. The usual way
around this is to say "A unique_multilock" like we do with "An array".
To be fair, this seems to be a consequence of copying pre-existing
wording, so you may as well keep it, or alternatively, fix the wording
for unique_lock in tandem. It also seems fine to come up with new
wording; that shouldn't be too hard.

3. You must not write "If sizeof...(Mutexes) == 1", as in, throwing a
C++ comparison expression into a prose condition. You can say "If
sizeof...(Mutexes) equals 1". These kinds of issues need to be fixed
up all over the place in your postconditions and other wording parts.

4. The declaration style in the standard draft is two add two-space
indent for function templates on the line after the template-head. The
editors would fix that up, but you may as well get it right in the
wording, and I think it improves readability, especially when there is
no syntax highlighting.

5. Having an "Effects: None" constructor seems bizarre. Isn't the
std::defer_lock_t constructor supposed to store the references to
mutexes within the class? If you don't mention storing these mutex
references, the specification of your constructors seems incomplete.

In general, there are large differences in quality between older
library wording and newer library wording, and you happen to be
copying ancient C++11 stuff.