@Barry: Was the reason for shooting the proposal down that the >> was
viewed as contentious with template close brackets or were there
non-syntax related issues? It does seem that at least => or -> is free
of such risks as = or - can't end a template declaration. Actually I
can't see any real parsing issue with >> either but that's another matter.

@Arthur:

Yoe are of course right in that conceptually move and forward are
different /operations/, but as  Barry noted in his proposal
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0644r1.html)
forward /does /the same thing as move except for lvalue references. I
think that if we have an easy to type forward operator such as -> it
will be used also for the move operation. And this is a good thing, as
it avoids the pitfall of accidentally moving out of universal references.

The long version:

What I was trying to say was that moving a lvalue reference is not a
very common situation, most moves we do today move by value variables or
rvalue reference parameters. When we write move on a universal reference
we are often not aware that our caller's by value variables will be
moved from without their consent, which leads me to believe that the
behavior of forward is the safe choice even when we write move. Example:


struct MyType {
// Standard setter pair
void setName(string&& n) { m_name = std::move(n); }
void setName(const string& n) { m_name = n; }

     string m_name;
};

// Forwarding function
template<typename T> void set(MyType& o, T&& n) { o.setName(move(n)); }
// #1

// Use
int main()
{
     MyType o;
     string name = "Tarzan";

     set(o, name);

   cout << "My name is " << name << ".";   // #2
}

(Godbolt: https://godbolt.org/z/51czae)

At #1 we move the n parameter as we want to use the best setter.
However, this should have been /forward/. Maybe we made this function a
template at a later stage, not realizing that we thereby made our
reference universal and move incorrect.

At #2 we see the consequences, the name variable is now in the move from
state, which typically outputs as the empty string.

So in this case move should definitely have been forward. I must say
that I'm hard pressed to find any valid use case for moving out of a
lvalue reference that does not arise due to a wrongly declared
parameter- or return type:

// Non-template version of above. The type should clearly have been
string&& to indicate to caller that it will move n out.
void f(MyType& o, string& n) { o,setName(move(n)); }

// If you really want to give away your name member you should not
return it by lvalue reference, choices are between rvalue reference or
by value.
string& releaseName() { return m_name; }

// If you have a lvalue reference you got as a return value it is
implied that you are allowed to change it, and moving out is a type of
change. But when
// the intention is to offer the reference for moving by value or by
rvalue reference is a way to indicate this and by always using forward
surprises can be avoided.
string& nn = releaseName();
o.setName(std::move(nn));

// The one valid use case of moving from a lvalue reference I could find
is when you have extracted a lvalue reference to a subobject and later
decide you can
// move from it.
ComplexObject obj;
string& userName = obj[ix].nameMap["user"];   // #3
if (userName can be safely moved out)
     o.setName(std.:move(userName));

My conclusion is that as long as you have a (non-const) lvalue reference
you got from somewhere else that don't know you're going to move from it
there is either the wrong return type/parameter type or a reliance of
moved from value being the same as the empty value. The use case at #3
is valid but rare. If we didn't already have move and were contemplating
addding a forwarding operator I would say that in this case
static_cast<string&&>(userName) would be the way to go, using the
forwarding operator for all cases when it behaves as move.

Maybe there is some prominent use case of move that I didn't see?

If not it seems that with a forwarding operator we should teach to use
it for both forward and move situations, avoiding nasty surprises
arising from selecting move instead of forward for brevity. Recommending
using static_cast for the specialist case when you find the optimization
of moving from a lvalue reference into a data structure you know enough
about to be certain that this is correct. With this in mind it seems
logical to look for another name than "forwarding operator".

An alternative would be to make the forwarding operator a forwarding
only operator by making it an error to apply it to a by value variable,
forcing the use of move in this case. However this begs the question
whether we also would add a move operator, which works for by value
variables and rvalue refeerences but not for lvalue references.
Personally I think that teaching would be easier with just one operator.

Background investigations:

A little test program (Godbolt: https://godbolt.org/z/cdfqsq) shows that
in most cases move and forward actually do the same thing. Soem coments:

The direct g calls show that moving or forwarding a by value variable
has the same result. (Also including the cast variants of forwarding).
This means that if the spelling of forwarding is shortest, it will often
be used even here, even though move is the /operation/.

The perfect forwarding in the f1 function works as intended, but the
moving as in g1 is often a bug as it will allow first m1 call to move
out of my x variable without indication at the m1 call site.

The same goes for the m3 function which takes the variable in the same
way and is not often correct: If a function like m3 moves the value out
its parameter type should be like m2.

Neither in the formal proposal or in the OP it has not been made clear
what the forward operator would mean when applied to a by value
variable. As seen by the second and third call to f1 (marked #2 and #3) 
there are two possibilities, and if the forwarding operator just uses
the variable type or with as a lvalue reference. However, the choice is
clear: It should be forwarded as the by value type. This is obvious by
the fact that if a lvalue reference would result the forwarding operator
would have no effect and be useless for local by value variables. Note
that this means that the forwarding operator (#2) now works exactly as
move (#4) when applied to by value variables.

Bengt