"since a function that takes an rvalue reference can take both rvalue references (unnamed temporaries) as well as lvalue references (named non-const references)"
This is an incorrect statement. During the first iterations of the rvalue reference specification this was true, but it no longer is and is implemented at least in MSVC to comply with this later change. In other words, this is illegal:
void f(char&&);
char x;
f(x);
In order to call a function expecting rvalue references with an lvalue you must turn it into an rvalue like so:
f(std::move(x))
Of course, that syntax makes it quite clear what the difference between a function taking an lvalue reference and one taking an rvalue reference really is: an rvalue reference is not expected to survive the call. This is a big deal.
Now, you can of course make up a new function that does exactly what std::move does and then you "can" use rvalue references sort of like lvalue references. I thought about doing this for instance with a visitor framework I have when sometimes you simply don't care about any result of the visitor call, but other times you do and thus need an lvalue reference in those cases. With an rvalue reference I could get both...but it's such a violation of the rvalue reference semantics that I decided it was a bad idea.
Your statement may be a confusion based upon this:
template < typename T >
void f(T&&);
char x;
f(x);
This works, but not because you are passing an lvalue as an rvalue reference. It works because of reference decay (also new in C++0x). When you pass an lvalue to such a template it actually gets instantiated like so:
void f<char&>(char&&&);
Reference decay says that &&&
turns into &
so then the actual instantiation looks like this:
void f<char&>(char&);
In other words, you're simply passing an lvalue by reference...nothing new or special about that.
Hope that clears things up.