The bound of considering the context of the copy-initialization

[dcl.init.general] p14 says

The initialization that occurs in the = form of a brace-or-equal-initializer or condition ([stmt.select]), as well as in argument passing, function return, throwing an exception ([except.throw]), handling an exception ([except.handle]), and aggregate member initialization ([dcl.init.aggr]), is called copy-initialization.

Consider this example:

struct T{
    explicit T(){}
};
T v = T();

The initialization occurs in the = form of a brace-or-equal-initializer, even though we have specified that the result object is direct-initialized by (). So the initialization is in the context of the copy-initialization? The explicit default constructor won't be considered for the default-initialization, according to [over.match.ctor] p1

For copy-initialization (including default initialization in the context of copy-initialization), the candidate functions are all the converting constructors ([class.conv.ctor]) of that class.

Presumably, It is not the intent of these rules. [dcl.init.general] p14 just contradicts the initialization specified for prvalue(e.g. which wants that the context is a direct-initialization).

This issue might relate to https://github.com/cplusplus/draft/issues/4582. We should remove [dcl.init.general] p14. What kind of initialization(i.e. copy or direct-initialization) should be decided/specified by the concrete rules.

Read [dcl.init.general] p14 and [over.match.ctor] p1 alongside the example in the issue, then compare the related discussion in issue #4582. Determine whether the copy-initialization wording conflicts with the intended treatment of the prvalue and explicit constructor; done means resolving that question and updating the affected standard wording if needed.