As discussed in the mentioned issue. If we prepare to restrict certain language constructs by using grammar, identifier is too flexible. Since lookup only concerns name and the entity introduced by the declaration. Even if we augment the definition of template-name, it is still not sufficient. Because of the identifier, we still need to draft the wording as that: if..., the name shall be introduced by a template declaration.

In order to make the restriction that is in terms of the grammar to work, we might have a formal rule that means as the following:

once an identifier(name) is determined which entity E it denotes after lookup, the identifier will be promoted to the corresponding component(e.g. class-name, namespace-name, or declarator-id) of the declaration of E. For some language constructs, their grammar requires the component to be class-name, namespace-name, which is the restriction to the name.

T::X * i; // #1

Whether the language construct at #1 is a declaration or expression is determined by what the identifier X denotes after lookup. If the identifier X denotes a class, it is promoted to be a class-name and only type-specifier can be a well-formed construct. Conversely, if X is determined to be an object, the identifier is promoted to unqualified-id( assume its declaration is int X = 1;), then only qualified-id can be a well-formed construct.

We need something like [class.pre] for templates.
Other than that, [gram.key] comes pretty close for the fact that we reinterpret an identifier as an X-name, except that it's a non-normative Annex.

[gram.key] comes pretty close for the fact that we reinterpret an identifier as an X-name

In translation phase 7, all preprocessing identifier tokens are just converted to an identifier token as specified in [lex.token]. I think we should also need a rule to explicitly state that the identifier will be reinterpreted to a high-level grammar(after lookup?), which can be convenient to limit the context where the identifier can be used. I think it is exactly the meaning of defining high-level grammar. We can say an unqualified-id can be an identifier but it is not the other way around, unqualified-id, therefore, is more special than an identifier. When an identifier is identified to be an unqualified-id, the latter can narrow the context where the identifier can be used.

struct X{};
int main(){
   X * i;
}

In translation phase 7, X is converted to an identifier, an identifier can be validly used in both multiplicative-expression and type-specifier(i.e. their grammars accept identifiers). There is no more restriction on an identifier. However, once we have a rule that specifies that the identifier X is reinterpreted to a class-name since lookup associates the use of the name with the class-specifier. This will result that the identifier X can only be used as a type-specifier. In other words, multiplicative-expression does not accept a class-name.

The quo status is, we just cannot clearly interpret why the identifier X cannot be used as an expression(i.e. unqualified-id) that is an identifier.

The quo status is, we just cannot clearly interpret why the identifier X cannot be used as an expression(i.e. unqualified-id) that is an identifier.

I think we've this part covered okay-ish: [expr.prim.id.unqual] p1 "An identifier is only an id-expression if it has been suitably declared (Clause 9) or if it appears as part of a declarator-id (9.3). An identifier that names a coroutine parameter refers to the copy of the parameter (9.5.4)."

suitably declared

I would say this is a bit unclear. What does the "suitably declared" exactly mean? We seem to have not given the concrete specification.
id-expression is a high-level grammar identity for these identifiers that are eligible to be that. Presumably, "suitably declared" means the identifiers should be introduced by the declarations that introduce these entities: object, reference, structured binding, function...

From certain perspectives, that means what declaration is found by lookup for that name, and therefore resulting in how the identifier will be reinterpreted or could say what high-level grammar identity the underlying identifier will be promoted to. That results will ultimately determine the context in which the use of the identifier is valid.

If possible, we should explicitly specify what the name will become when a declaration introduces it. Similar to [class.pre] have done.

A class is a type. Its name(i.e. identifier) becomes(i.e. promoted to) is reinterpreted as a class-name ([class.name]) within its scope.

And we might make a rule and add it to [basic.lookup], the rule might mean

the name that is an identifier is reinterpreted by the found declaration for further syntactical and semantic analysis.

Then we will clearly know the reason why we categorize the identifiers into various high-level grammar stuff.