I think we mean that the qualified-id needs to be in a type-only context, not just its terminal name. Any rephrasing should retain that meaning.

However, [temp.res#general-4] is saying so, that is

A qualified or unqualified name is said to be in a type-only context if it is the terminal name of

• [...]

In other words, the qualified or unqualified name first refers to the terminal name of something and we say they are in a type-only context if the terminal name(qualified or unqualified name) satisfies some conditions. The meaning is more clear in [basic.lookup.qual#general-2]. On another hand, if a terminal name of something is in that context, of course, the something that comprises the name is also in that context.

@opensdh, regarding [temp.res.general] p4:

I think it doesn't make sense to claim that a terminal name can be qualified; the rules for "terminal name" would kill any qualification. If you agree, p4 should just say "A name is said to be in a type-only context if it is the terminal name of ..."

UPDATE: I'm confused. "qualified name" is different from qualified-id. The wording does make sense as-is, but I'd still just say "name".

Given this clarification, the original issue here (add "if and only if") seems plausible; what do you think?

AFAIK, the term qualified name has a formal definition, which is defined in [basic.lookup.qual#general-2]

A qualified name is

• a member-qualified name or
• the terminal name of

• a qualified-id
• [...]

In other words, the terminal name of one of the components in the list is called a qualified name, IMO, [temp.res.general] p4 seems to have no problem(a qualified name is the terminal name of ...), at least, there is no conflict here.

In addition, [temp.res.general] p4 in most respects is saying the terminal name of a qualified-id(even if it should be a simple-type-specifier on grammar), which is another #4791 issue.

Given this clarification, the original issue here (add "if and only if") seems plausible; what do you think?

I think this rephrasing is an improvement, although this section is going to get rewritten for the "non-expression qualified-id" issue anyway.

@opensdh For "non-expression qualified-id", the rewritten content is #4793