[class.access.base] p5 Whether the base-specifier-list of a derived class is a point R where protected member is accessible? CWG372

We define whether a member of naming class N is accessible at R is as the following:

A member m is accessible at the point R when named in class N if

• [...]
• m as a member of N is protected, ..., or in a member of a class P derived from N, where m as a member of P is public, private, or protected, or

It does not mention the base-specifier-list of class P. Consider this example:

struct N{
 protected:
    struct Base{};
};
struct P: N::Base, N{};

member Base is named in class N and N is a base class of class P. However, as defined above, we just say Base is accessible in the member of P. We do not explicitly say that Base is accessible at R that occurs in base-specifier-list of P. Although, we mention it in [class.access.general] p1

A member of a class can be

• [...]
• protected, that is, it can be named only by members and friends of the class in which it is declared, by classes derived from that class, and by their friends (see [class.protected]); or

However, it is not the definition of whether the member is accessible. Since we only phrase the following rule based on whether the members or base classes are accessible

The interpretation of a given construct is established without regard to access control. If the interpretation established makes use of inaccessible members or base classes, the construct is ill-formed.

We can see that implementations have a divergence interpretation to this example.

Start with [class.access.base] and the cited [class.access.general] wording, then run the linked Compiler Explorer example to compare implementations. Done means the standard explicitly resolves whether access at R includes a base-specifier-list and removes the observed interpretation divergence.