The initializer or initializer expression in whole [dcl.init]

This issue is trying to conclude the several issues about the wording initializer in clause [dcl.init] and [dcl.type.auto.deduct]. Maybe a bit of part thereof is duplication with the latest issue I posted.

what's the definition of non-italic wording "initializer" or "initializer expression" in these bullets of [dcl.init]?

Regard the definition of "initializer expression", it's also mentioned in issue #2934. IMHO, the whole clause [dcl.init] states how the initialization will be applied to is based on the relation between either "initializer" or "initializer expression" and destination type. Does the non-italic "initializer" and "initializer expression" refer to the initializer on grammar belongs to [dcl.init#nt:initializer] or refer to a more generalization concept? If it's the former, it will make no sense that these bullets regard of initialization do not apply to such as "Y X-initialized from E" where E is not the initializer that follows the declarator in a declaration(i.e, on grammar). As well as "initializer expression", since there's no normative definition for what it is. I think it is the constitute expression of the initializer(that is not braced-list-initializer). Consider the following rule

The call is used to direct-initialize,..., the object that is the destination of the copy-initialization. [dcl.init#general-15.6.3]

struct A{
   A(int){}
};
A a = 0;  //#1

I would say that the call A::A(0) is not the initializer that appears within the declaration at #1. Instead, in that declaration, =0 is the initializer. Does it mean the bullet [dcl.init.general#15.6.1] does not apply to "a drect-initialized from the call" since it uses "initializer expression" where the initializer is considered has the meaning of the grammar. Hence, for such a statement similar to "Y X-initialized from E", I think it is necessary to introduce a hypothetical declaration as if E would be the initializer in the declaration and clarify what's the "initializer expression".

The issue of "initializer" in [dcl.type.auto.deduct]

The first paragraph of [dcl.type.auto.deduct#2] defines that E is an initializer. It appears to me that #4315 is just a partial fixed for issue #4088. I think we should clarify what E is wherever the expression is required instead of simply giving an initializer. Such as:

auto a(0);

If as per [dcl.type.auto.deduct#2.2], E should be (0)(the initializer). Even if we can considered (0) as a parenthesized primary-expression when undergoing [dcl.type.auto.deduct#4], fortunately, there's no effect to the expression category and type of the result. However, the following is quite different

int b = 0;
decltype(auto) a(b);

As well, E is (b), if as per [dcl.type.auto.deduct#5], the type of a should be decltype((b)), unfortunately, the type of a would be int& as per [dcl.type.decltype#1.5]. However, it should have been int as the example said. In this case, the "initializer" has modified the category of the result.

The readability of initialization of result object stated in [dcl.init]

Such as [dcl.init.list#3.10]

Otherwise, if T is a reference type, a prvalue is generated. The prvalue initializes its result object by copy-list-initialization.

The sentence is only talking about what's the kind of initialization to initialized its result object, but what's the source? Is that "The prvalue initializes its result object by copy-list-initialization with the initializer" is more readable? As the same manner as [expr.type.conv#2] does

the expression is a prvalue of the specified type whose result object is direct-initialized with the initializer

That will make it clear what's the initializer is in the sentence when we fall into [dcl.init.list#3.9](assume the previous case is int&& a = {0};), if my first point is approved too, the hypothetical declaration for "temporary is copy-initialized from the initializer" will be

int temporary  = {0};

The initializer is clearly the initializer within int&& a = {0};, and the purpose of the hypothetical declaration is making {0} be an initializer when interpreting the wording "initializer" in bullet [dcl.init.list#3.9]

Otherwise, if the initializer list has a single element of type E and either T is not a reference type or its referenced type is reference-related to E, the object or reference is initialized from that element (by copy-initialization for copy-list-initialization, or by direct-initialization for direct-list-initialization); if a narrowing conversion (see below) is required to convert the element to T, the program is ill-formed.

It seems non-reasonable that the array type with the initializer that has the form parenthesized expression-list is forbidden by [expr.type.conv]

If the initializer is a parenthesized optional expression-list, the specified type shall not be an array type.

However, since the bullet [dcl.init#general-15.5] has permitted such initialization why doesn't [expr.type.conv] permit?

It might be not considered an editorial. However, IMHO, it's useful for the readability of the whole [dcl.init].

Start by reading [dcl.init], [dcl.type.auto.deduct], [dcl.init.list], and [expr.type.conv], then compare the related discussions in issues #2934, #4315, and #4088. The issue requires resolving several interacting terminology and wording questions; done would mean an agreed, consistent specification change covering the identified cases.