That was noticed in core issue 1222 as well, but the main topic (and thus the core issue) was rejected as NAD. Seems like a bug in the wording.

Yes, the "then the type of the identifier of D is an array type" part is nonsense. We could say "then the type of the identifier of D is an array type if the derived-declarator-type-list is empty", but I'd really prefer to omit that entirely.

The "T is called the array element type" part is not really wrong but not useful. This wording is only concerning the case where the [...] is the outermost part of the declarator, in which case T actually is the array element type. However, in a declaration in which we have a non-outermost array declarator chunk, such as:

int *p[42];

we are told to form the type of "int p[42]", then remove the "int" part and replace it with "pointer to int" (eg, "array of 42 int" -> "array of 42 pointer to int"), and the array element type of the resulting array type is never defined.

We also have no link between the type "array of N T" and the term "array type" from [basic.compound] other than the wrong statement "then the type of the identifier of D is an array type".

Perhaps we should define the canonical type strings in [basic.compound], move the definition of "array element type" there, and in [dcl.array] just specify how the canonical type string is formed.

@zygoloid, I'm unhappy with the larger change "Perhaps we should define the canonical type strings in [basic.compound]" done editorially, but do you think we can do a small localized fix editorially, or do we need CWG input for that?

Okay, I've tried a rewording of [dcl.array]. Looks much saner to me now.