This is all part of the entity (variable) vs. object confusion

A plethora of verbs appear to be in use to talk about the object to which a glvalue or a reference refers.

[conv.lval] p3 uses "refers" and "indicated".

[basic.lval] p5 and p11 uses "denotes"

We should use a consistent verb form here.

It seems "denotes" should be used for "the result of name lookup", e.g. a name denotes a variable or a function. See basic.pre p5. We should pick another verb for references and glvalues.

We should use a consistent verb form here.

Yes, this is the concern of this issue. Furthermore, we don't give a consistent meaning to "reference binding" as well.

Consider [dcl.init.ref] p5.1 and p5.3

then the reference binds to the initializer expression lvalue in the first case and to the lvalue result of the conversion in the second case (or, in either case, to the appropriate base class subobject of the object).

In any case, the reference binds to the resulting glvalue (or to an appropriate base class subobject).

So, whether the reference binds to the expression or an entity(i.e. an object or a function)? In [over.ics.rank] subclause, we basically say the reference binds to either an lvalue or rvalue(i.e. the expression).

It seems "denotes" should be used for "the result of name lookup", e.g. a name denotes a variable or a function. See basic.pre p5.

Agree! "denote" is correctly used in [expr.prim.id.unqual] and [expr.prim.id.qual]. First, [basic.pre] p5 says

An entity E is denoted by the name (if any) that is introduced by a declaration of E

The name could be an unqualified name or a qualified name.

[expr.prim.id.unqual] p3 says

The result is the entity denoted by the unqualified-id ([basic.lookup.unqual]).

[qualified-id] p5 says

The result of a qualified-id Q is the entity it denotes ([basic.lookup.qual]).

[qualified-id] p5 might be clearer after adopting cplusplus/draft#5346

I think once we determine that the "verb" X is what we want to pick for glvalue. we might use it in [expr.prim.id.unqual] and [qualified-id] p5 to specify what entity is Xed by unqualified-id or qualified-id when they are lvalue.

The problem is that we use qualified-id and unqualified-id both for the expression / glvalue sense (which object are we talking about?) and in the identifier sense (which variable or data member are we talking about?) Those two meanings need to get a clear divorce, and the right approach is to move the variable / data member interpretation into [basic], and only leave the glvalue / expression interpretation in [expr].

The problem is that we use qualified-id and unqualified-id both for the expression / glvalue sense (which object are we talking about?) and in the identifier sense (which variable or data member are we talking about?)

IIUC, do you mean that the name of a variable or data member can be associated with several objects? I want to divorce objects from variables. "variable" should have a pure meaning that its name could be used to refer to (conceptually) objects or references as determined by the declaration. For the problem that which object is designated/referred to by the name, I think it is determined by the evaluation of the glvalue.

In the current, the entity is an object, function, or something else specified in [basic.pre].

The result is the entity denoted by the unqualified-id ([basic.lookup.unqual]).

I construe this rule as that the name is used to denote (conceptually)objects rather than the concrete object. Because [basic.lookup] only associates the name with the found declaration, it cannot determine which object the name refers to. This part has been discussed in cplusplus/draft#5346 (comment)

do you mean that the name of a variable or data member can be associated with several objects?

Yes. Think about a local variable in a recursive function: you get a different object for each invocation.

do you mean that the name of a variable or data member can be associated with several objects?

Yes. Think about a local variable in a recursive function: you get a different object for each invocation.

The problem coincidently falls into the discussion about variables in cplusplus/draft#5346. We want "variable" to be an entity(object is not an entity), then the name denotes the "variable", as @opensdh said in cplusplus/draft#5346 (comment). The "reference" should also have the same problem(per thread or in a recursive function). We might consider "use a consistent verb" as the primary concern in this issue.