[expr.ref] p1 The evaluation of the id-expression in class member access

In the c++20 document, [expr.const p5 says

An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine ([intro.execution]), would evaluate one of the following:

• [...]
• 5.8 an lvalue-to-rvalue conversion unless it is applied to

• a non-volatile glvalue that refers to an object that is usable in constant expressions, or
• a non-volatile glvalue of literal type that refers to a non-volatile object whose lifetime began within the evaluation of E;

• [...]
• 5.12 an id-expression that refers to a variable or data member of reference type unless the reference has a preceding initialization and either

• it is usable in constant expressions or
• its lifetime began within the evaluation of E;

Consider this example:

struct A{
   int const& rf;
};
constexpr int value = 10;
A a{value};
constexpr int v = a.rf;  // error

a.rf does refer to the object value that is usable in constant expressions. The only possible reason why the initialization is not a constant expression should be 5.12. The wording of 5.12 is changed in the current draft, however, which has a similar meaning for this case.

[expr.const] p7

For such a reference that is not usable in constant expressions, the reference is treated as binding to an unspecified object of the referenced type whose lifetime and that of all subobjects includes the entire constant evaluation and whose dynamic type is constexpr-unknown.

So, this issue remains that whether the evaluation of the class member access would evaluate the id-expression. [expr.ref] p1 says

The postfix expression before the dot or arrow is evaluated; the result of that evaluation, together with the id-expression, determines the result of the entire postfix expression.

It is a bit vague whether the id-expression is evaluated. The improvement might be

The postfix expression before the dot or arrow is evaluated; the result of that evaluation, together with the evaluation of the id-expression, determines the result of the entire postfix expression.

The change makes the implied meaning clearer.

Another issue is, whether we admit that the post-expression in the class member access is sequenced before the id-expression

Start by reading [expr.const] paragraphs 5 and 7 and [expr.ref] paragraph 1 in the draft, then examine the issue's proposed wording and the unresolved sequencing question. Done means reaching and documenting a standards-backed resolution for whether the id-expression is evaluated and sequenced, with corresponding draft wording.