Why "universal references" have the same syntax as rvalue references?

I just made some research about those (quite) new features and I wonder why C++ Committee decided to introduce the same syntax for both of them? It seems that developers unnecessary have to waste some time to understand how it works, and one solution lets to think about further problems. In my case it started from problem which can be simplified to this:

#include <iostream>

template <typename T>
void f(T& a)
{
    std::cout << "f(T& a) for lvalues\n";
}

template <typename T>
void f(T&& a)
{
    std::cout << "f(T&& a) for rvalues\n";
}

int main()
{
    int a;
    f(a);
    f(int());

    return 0;
}

I compiled it firstly on VS2013 and it worked as I expected, with this results:

f(T& a) for lvalues
f(T&& a) for rvalues

But there was one suspicious thing: intellisense underlined f(a). I made some research and I understood that it is because type collapsing (universal references as Scott Meyers named it), so I wondered what g++ thinks about it. Of course it didn't compiled. It is very nice that Microsoft implemented their compiler to work in more intuitive way, but I'm not sure if it is according to the standard and if there should be this kind of difference in IDE (compiler vs intellisense, but in fact there may be some sense in it). Ok, return to the problem. I solved it in this way:

template <typename T>
void f(T& a)
{
    std::cout << "f(T& a) for lvalues\n";
}

template <typename T>
void f(const T&& a)
{
    std::cout << "f(T&& a) for rvalues\n";
}

Now there wasn't any type collapsing, just normal overloading for (r/l)values. It compiled on g++, intellisense stopped complaining and I was almost satisfied. Almost, because I thought about what if I will want to change something in object's state which is passed by rvalue reference? I could describe some situation when it could be necessary, but this description is too long to present it here. I solved it in this way:

template <typename T>
void f(T&& a, std::true_type)
{
    std::cout << "f(T&& a) for rvalues\n";
}

template <typename T>
void f(T&& a, std::false_type)
{
    std::cout << "f(T&& a) for lvalues\n";
}

template <typename T>
void f(T&& a)
{
    f(std::forward<T>(a), std::is_rvalue_reference<T&&>());
}

Now it compiles on all tested compilers and it lets me to change object state in rvalue reference implementation, but it doesn't looks very nice, and this is because of the same syntax for universal references and rvalue references. So my question is: Why C++ Committee didn't introduce some another syntax for universal references? I think that this feature should be signalized, for example, by T?, auto?, or something similar, but not as T&& and auto&& which just collide with rvalue references. Using this approach my first implementation would be perfectly correct, not only for MS compiler. Can anyone explain Committee decision?

I think it happened the other way around. The initial idea was to introduce rvalue-references into the language, meaning that "the code providing the double-ampersand reference does not care about what will happen to the referred-to object". This permits move semantics. This is nice.

Now. The standard forbids constructing a reference to a reference, but this was always possible. Consider:

template<typename T>
void my_func(T, T&) { /* ... */ }

// ...

my_func<int&>(a, b);

In this case the type of the second parameter should be int & &, but this is explicitly forbidden in the standard. So the references have to be collapsed, even in C++98. In C++98, there was only one kind of reference, so the collapsing rule was simple:

& & -> &

Now, we have two kinds of references, where && means "I don't care about what may happen to the object", and & meaning "I may care about what may happen to the object, so you better watch what you're doing". With this in mind, the collapsing rules flow naturally: C++ should collapse referecnces to && only if no one cares about what happens to the object:

& & -> &
& && -> &
&& & -> &
&& && -> &&

With these rules in place, I think it's Scott Meyers who noticed that this subset of rules:

& && -> &
&& && -> &&

Shows that && is right-neutral with regards to reference collapsing, and, when type deduction occurs, the T&& construct can be used to match any type of reference, and coined the term "Universal reference" for these references. It is not something that has been invented by the Committee. It is only a side-effect of other rules, not a Committee design.

And the term has therefore been introduced to distinguish between REAL rvalue-references, when no type deduction occurs, which are guaranteed to be &&, and those type-deduced UNIVERSAL references, which are not guaranteed to remain && at template specialization time.

Others have already mentioned that reference collapsing rules are key for universal references to work but there's another (arguably) equally important aspect: template argument deduction when the template parameter is of the form T&&.

Actually, in relation to the question:

Why “universal references” have the same syntax as rvalue references?

in my opinion the form of the template parameter is more important because this is all about syntax. In C++03 there was no way to a template function to know the value category (rvalue or lvalue) of the passed object. C++11 changed the template argument deduction to account for that: 14.8.2.1 [temp.deduct.call]/p3

[...] If P is an rvalue reference to a cv-unqualified template parameter and the argument is an lvalue, the type "lvalue reference to A" is used in place of A for type deduction.

This a bit more complicated than the originally proposed wording (given by n1770):

If P is an rvalue-reference type of the form cv T&& where T is a template type-parameter, and the argument is an lvalue, the deduced template argument value for T is A&. [Example:

template<typename T> int f(T&&);
int i;
int j = f(i);   // calls f<int&>(i)

--- end example]

In more detail, the call above triggers the instantiation of f<int&>(int& &&) which, after reference collapsing is applied, becomes f<int&>(int&). On the other hand f(0) instantiates f<int>(int&&). (Notice there's no & inside < ... >.)

No other form of declaration would deduce T to int& and trigger the instantiation of f<int&>( ... ). (Notice that a & can appear between ( ... ) but not between < ... >.)

In summary, when type deduction is performed the syntactic form T&& is what allows the value category of the original object to be available inside the function template body.

Related to this fact, notice that one must use std::forward<T>(arg) and not std::forward(arg) exactly because it's T (not arg) that records the value category of the original object. (As a mesaure of caution, the definition of std::forward "artificially" forces the latter compilation to fail to prevent programmers making this mistake.)

Back to the original question: "Why the committee decided to use the form T&& rather than choose a new syntax?"

I can't tell the real reason but I can speculate. First this is backward compatible with C++03. Second and, most importantly, this was a very simple solution to state in the Standard (one paragraph change) and to implement by compilers. Please, don't get me wrong. I'm not saying the committee members are lazy (they certainly aren't). I'm just saying that they minimized the risk of collateral damage.

You answered your own question: "universal reference" is just a name for the rvalue reference case of reference collapsing. If another syntax were required for reference collapsing, it wouldn't be reference collapsing any more. Reference collapsing is simply applying a reference qualifier to a reference type.

so I wondered what g++ thinks about it. Of course it didn't compiled.

Your first example is well-formed. GCC 4.9 compiles it without complaint, and the output agrees with MSVC.

Almost, because I thought about what if I will want to change something in object's state which is passing by rvalue reference?

Rvalue references do not apply const semantics; you can always change the state of an object passed by move. Mutability is necessary to their purpose. Although there is such a thing as const &&, you should never need it.