https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84231
--- Comment #3 from Alexandre Oliva <aoliva at gcc dot gnu.org> --- The difference arises because, when resolving the % overload in normal_function, the result operands of the ternary operator have gained rvalue-forcing NOP_EXPRs, which makes their lvalue_kind clk_none, so the ref-binding is a bad conversion and the non-const template is not viable, but within function_template, the rvalue-forcing casts aren't there, so lvalue_kind for the ternary operator results is clk_ordinary, and reference_binding is regarded as acceptable, and so both operator%s are viable, and the one without const is later selected as a better match. I suppose the parsing of the ternary operator should behave the same way, given that nothing is dependent in the expression. But when processing_template_decl, build_x_conditional_expr creates a COND_EXPR node with the original operands. Oops.
