Hot(rvalue) Referencing and move proposal

first:
I find the 'r/l-value reference' terminology rather confusing and I
find the following names for this new refrence type more suitable:

temporary reference:
Since it is generally intended to refere to temporary objects

Immidiate referenc:
Since literals are assumed as temporary in C++ and immidiate or quick
in assembly language.

hot reference:
Temporary objects remind me of supernovas they die immidiately after
birth.According to lifetime we know that temporary lives on a single
line of code,an auto lives inside the block in which it is
defined ,static lives as long as it is refered to(longer than
auto),dynamic objects do not have a predefined lifetime;they live at
least one line of code and at most upto the end of program.So we see
that temporary is so hyperactive,so short lasting,so HOT.Since all
other storage classes have a longer liftime than a temporary, they
could be treated as if they were temporary - as long as the temporary
is not assumed to be destroyed after use(just like the swap example in
the move proposal).

every first is followed by a next:
I have been digging inside the move proposal(http://www.open-std.org/
jtc1/sc22/wg21/docs/papers/2002/n1377.htm).Although it invokes a
killing desire inside me,letting a hot refrence argument to be
returned is really disturbing.This example was exstracted out of the
move proposal document:

string&&
operator+(string&& x, const string& y)
{
    return x += y;
}

Neglecting the 'operator+=' ,Had we declared 'x' and return type of
'operator+' as cold const references in this piece of code (ie 'const
string& operator+(const string& x, const string& y)'),according to
existing standards 'x' should have been destroyed immidiately after
'operator+' returns; therefor the return value of 'operator+' would be
undefined .However destruction of 'x'could be Postponed in expense of
a minimal stack memory overhead . now take the following more complex
example:

class huge_type;

huge_type&& go(huge_type&& x,huge_type&& y){

    ...

    if(...){

        ...

        return x;
    };

    ...

    return y;
};

Here the the function 'go' must decide whether the destruction of 'x'
or 'y' is to be performed/postponed just before returninig (). The
stack overhead might be different for 'x' and 'y'- according to
evaluation order of objects . Since huge_type is big in size ,this
approach might be overmuch stack-consuming .A normal return with a
move construction would be a better solution specially if the
destructor and move constructor are trivial ones-in which case the
stack overhead could implicitly be removed in expense of a minimal mem-
copy(move) run-time overhead for the worst case.