Proposed resolution (approved by CWG 2023-11-11):

1. Change in 9.4.4 [dcl.init.ref] bullet 5.3 as follows:

   Otherwise, if the initializer expression

   • is an rvalue (but not a bit-field) or function lvalue and “cv1 T1” is reference-compatible with “cv2 T2”, or
   • 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.2.2.7 [over.match.ref]),

   then the initializer expression in the first case and the converted expression in the second case is called the converted initializer. If the converted initializer is a prvalue, let its type be denoted by T4; the temporary materialization conversion (7.3.5 [conv.rval]) is applied, considering the type of the prvalue to be is adjusted to type “cv1 T4” (7.3.6 [conv.qual]) and the temporary materialization conversion (7.3.5 [conv.rval]) is applied. In any case, the reference binds to the resulting glvalue (or to an appropriate base class subobject).

2. Append to the example in 9.4.4 [dcl.init.ref] bullet 5.3 as follows:

     B&& rrb = x;  // binds directly to the result of operator B
     const int& r2 = 0;  // binds directly to temporary of type const int
   

3. Change the example in 9.4.4 [dcl.init.ref] bullet 5.4 as follows:

     const double& rcd2 = 2;   // rcd2 refers to temporary with type const double and value 2.0
   

Core issue 2481 was resolved by clarifying that the temporary object in p5.4.2 is cv-qualified if the reference being initialized is cv-qualified. However, this is not the right bullet point for the example given,

  constexpr const int &r = 42;

Such an initialization would actually use bullet 5.3.1 instead. (5.4.2 would be used if the initializer were, for example, 3.14.) We therefore need to make a similar clarification in bullet 5.3, and ideally using the same language.