https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546
--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> --- This changed from the fix for PR 86521. As you say, deduction is first done with P = T&&, A = const Foo&, and deduces 'const Foo' for T. This produces operator const Foo&&. But according to [over.match.ref], we don't consider a conversion function yielding an rvalue reference (const Foo&&) for direct reference binding to an lvalue reference (const Foo&), so we fall back on creating a temporary Foo and binding the reference to that. On the other hand, the rules in [dcl.init.ref] are more forgiving; this case seems to hit the bullet Otherwise, if the initializer expression...has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be converted to an rvalue or function lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3” (see 12.4.1.6), then the value of the initializer expression in the first case and the result of the conversion in the second case is called the converted initializer.... In any case, the reference is bound to the resulting glvalue (or to an appropriate base class subobject). So if we ignored the [over.match.ref] rule we would happily bind directly to the xvalue from operator const Foo&&. The standard is definitely unclear here, but no other implementation agrees with us on this testcase. I suppose for now I'll limit the [over.match.ref] limitation to only apply to non-template conversions.
