I don't see myself ever getting on board with this auto-ref idea. I just
think it's crazy. It makes no sense to me, they are completely unrelated
concepts. It will only lead to confusion.

I'm back at scope-ref. Kenji is right as far as I'm concerned. Not to
mention, he actually did the work.
It makes perfect sense, and I can't see any reason why auto-ref should be
used instead of something that actually makes intuitive sense, and people
will eventually want to use anyway...

I'm against "scope ref" as the one thing "scope" means is that the parameter cannot be returned, and preventing rvalue references being returned breaks the one thing they are useful for.

The primary use of rvalue references in C++ is so that these three cases work:
vector<T> vec;
T t;
vec.push_back(T()) // Move semantics (temporary is destroyed in the process)
vec.push_back(t) // Copy semantics ('t' is unmodified)
vec.push_back(move(t)) // Move semantics ('t' is destroyed in the process)

This allows best efficiency (move is at least as fast as copy, so when the original is no longer needed a move should be performed)

The way it works is that push_back() has two overloads:
push_back(T&& v) {
    // Move 'v' into the vector, afterwards 'v' will have had its guts ripped out so to speak...
}
push_back(const T& v) {
    // Copy 'v' into the vector, 'v' is unmodified
}

- r-values such as 'T()' will default to the first overload.
- l-values such as 't' will default to the second overload.
- 'move(t)' returns an r-value causing the first overload to be called.

As you can see, using "scope ref" will break this third case because 'move()' won't be able to return an r-value, and if only the first two cases are going to be possible, this can be done without any special notion of r-value references anyway.

I'm starting to think there does need to be new syntax if all three of the above cases are to be covered - it would work just making "ref" accept rvalues but then "move" would be the default for lvalues, and that would be confusing - but I don't think using "scope" solves any problems, as the semantics required for rvalues are orthogonal to what "scope" actually means.

As good as it is to avoid adding new keywords, I think this might be a case where it's warranted...