The status quo wording fails to implement the design intent of P0960; right now, the wording does not allow single-argument parenthesized initialization, function-style casts, static_casts, or C-style casts if the conversion's target type is an aggregate. The parenthesized initialization creates a special case where parenthesized initialization with multiple arguments is well-formed, but where parenthesized initialization with one argument is ill-formed.
In addition to conveniently making library facilities such as make_shared Just Work with aggregates, the whole point of P0960 is to remove special cases. The validity of parenthesized initialiation should not (and in fact must not) depend on the number of arguments (unless there are more arguments than there are elements to initialize, of course).
Note that the avoidance of special cases doesn't mean special cases in the technical wording; it means special cases in how to write programs.
Some arguments have been made that static_casting from fewer arguments than there are elements is unfortunate. However,
P0960 wasn't designed with a specific goal of making static_casts work; however, it was designed with the specific goal that if braced-init is valid, paren-init should be valid, and by extension, if one kind of initialization is valid, other kinds of initialization should also be valid. Prior to P0960, parenthesized aggregate initialization was valid for some cases (copy/move), and its intent was to remove the warts where a form of initialization was not valid solely because the target type is an aggregate. Aggregates are supposed to be simple and straightforward; prior to P0960, the special-case rules strongly recommended users to avoid those special cases by turning their aggregates into non-aggregates by adding constructors, which is very much counter-productive.
An anonymous contributor, known to be an expert in both The Queen's English and forging iron, helpfully provided the wording for this fix.
Change in [expr.static.cast]p4:
An expression e can be explicitly converted to a type T if there is an implicit conversion sequence (184.108.40.206) from e to T,
orif overload resolution for a direct-initialization (9.4) of an object or reference of type T from e would find at least one viable function (12.4.2). [...reference case...] Otherwise, the result object is direct-initialized from e. [Note: The conversion is ill-formed when attempting to convert an expression of class type to an inaccessible or ambiguous base class. —end note]