The grammar template-name component has a narrow definition

template-name:

• identifier

template<class T>
struct X{};  // #1

X<int> v;  // #2

X is a class-name introduced by the declaration at #1. However, a simple-template-id is defined as:

template-name < template-argument-list _opt >

template-name cannot be a class-name. Unlike other grammar definitions, they include as many as possible grammar components that can be used to form that grammar. Specifically, such as the qualified-id:

• nested-name-specifier template_opt unqualified-id

where the grammar nested-name-specifier is defined as:

• [...]
• type-name
• namespace-name
• [...]

where the grammar type-name can be broken up into that:

• class-name
• [...]

That means, the grammar in the following example all can be covered

struct X{
   static int value;
};
namespace A{
  int a = 0;
}
int main(){
   sizeof(X::value) + A::a;
}

X:: and A:: are nested-name-specifiers where the first is class-name and the second is namespace-name, even though they ultimately are identifiers. Conversely, the template-name in a simple-template-id just includes an identifier. That is, it greatly limits what the components are. Although, [temp.names.note] p1 implies that a name that is an identifier can be reinterpreted as a template-name if possible. However, it is not a formal rule. The quo status is, a component can only be a template-name when we have explicitly specified it is a template-name. Such as [temp.alias] p1

The name of the alias template is a template-name.

Start with the grammar definitions for template-name and simple-template-id, then read [temp.names.note] p1 and [temp.alias] p1 as cited in the issue. Compare those rules with the X and A examples; done means the draft has an agreed, formally consistent treatment of names that can serve as template-names.