This seems non editorial and should be sent to https://cplusplus.github.io/LWG/lwg-active.html#submit_issue

That said, if the rvalue reference is a unique reference to the argument, the caller can't tell if it gets moved. The intent of Note 2 is to say that explicitly casting an lvalue to an rvalue and passing it to a function that binds an rvalue reference to it can assume the caller isn't going to inspect it, or at least can't assume it won't be moved.

That said, if the rvalue reference is a unique reference to the argument, the caller can't tell if it gets moved.

I read those sentences, but couldn't answer the question: "unique reference, in which scope?". The Note 2 says:

The implementation is free to optimize away aliasing checks which might be needed if the argument was an lvalue.

I read this to mean that the reference can be assumed to be unique within the implementation of the standard library API, in pretty much the same way that C's restrict works.

That is:

foo a, b, c;
void std_lib(foo&& a, foo&& b); // similar to `std_lib(foo restrict* a, foo restrict* b);
std_lib(move(a), move(b)); // OK
std_lib(move(c), move(c)); // UB: violates unique reference

I'm not sure what else it could mean either. If we extend the scope to the caller, then it could mean that, e.g.,

auto token = barrier.arrive();
auto ptr = &token; // copy address
barrier.wait(move(token));  // UB: not unique

This wording about "unique reference" and its intent could definitely be made more clear as well.

auto token = barrier.arrive();
auto ptr = &token; // copy address
barrier.wait(move(token));  // UB: not unique

That's what it means, except it doesn't say anything about it being undefined to have another reference. It just means the library can assume that the caller cannot (or will not) inspect the value after the call. Therefore, it's OK to move from it. The origin of the wording is LWG issue 1204: Global permission to move. The name of the issue and the discussion make it pretty clear moving is intended. It says "If v is truly bound to a temporary, then push_back has the only reference to this temporary in the entire program." It's definitely not talking about "unique within the implementation of the standard library API", it's talking about the whole program.

This is clearly not editorial and so this is the wrong venue to discuss it.

Thanks, I'll file a proper issue. I agree that the intend is clear, which is why I thought that this clarification could be an editorial change. Sorry for the misunderstanding.

This is moving to the LWG issues list.