"Result" is defined as the value/object returned by the function call, so I don't think that's quite right. We want to say that the call expression is an lvalue or xvalue. Maybe:

A call to a conversion function returning "reference to X" is a glvalue of type X, and such a conversion function is therefore considered to yield X for this process of selecting candidate functions.

?

Strictly speaking, we don't need "therefore" in normative text. We're not arguing, we're defining rules. Just saying "A conversion function returning "reference to X" is considered to yield X for this process of selecting candidate functions." is good enough. But, we're sometimes a bit tutorial-esque in the standard, so why not here, too?

"Result" is defined as the value/object returned by the function call, so I don't think that's quite right.

Then the note [basic.lval]/4 needs fix? It says "An expression is an xvalue if it is: the result of calling a function, whether implicitly or explicitly, whose return type is an rvalue reference to object type"

There already exists PR about [basic.lval]/4 — #2045 — so could the fix for "xvalue is ... the result of calling a function" be added into it?

I'm inclined to call this NAD. I have no problem with "returning an xvalue"; in fact, that's how I usually say it myself when the distinctions matter.

To me, this fits as follows: as a general statement that I think sounds meaningful to most programmers, regardless of language, "a function returns a value" is a useful shorthand for "the result of evaluating a function call expression is a value". Now all we're doing is extending this schema to be specific about the category of that value.

Jens's change is fine (though I think we'd be OK without it, too), but I wouldn't want to consider "f returns an int lvalue" to be inappropriate language. I find it very useful and concise language.