Relaxing Restrictions on Arrays, P1997 (https://wg21.link/p1997)

proposes C array copy semantics, in initialization and assignment.

E.g. P1997 makes 0..4 below well-formed copy operations:

int f()[2]         // #0
{
    int a[2] = {1,2};
    int b[2] = a;  // #1
    a = {3,4};     // #2
    b = a;         // #3
    return {0,1};  // #0
}
int c[] = f();     // #4

error 0: 'f' declared as function returning an array
error 1: array initializer must be an initializer list
error 2: assigning to an array from an initializer list
error 3: invalid array assignment

error 4: c.f. errors 0 and 1

My question:
Does anyone foresee issues once arrays appear in initializer lists?

Potential breakages, other change in behaviour, challenges in the

specification, and its required wording, or the implementation

(initializer lists seem a dark corner where implementers fear to tread)?

The one existing case where C and C++ admit array copy semantics

is character array initialization from string literal:

    char hi[] = "hi";
    char ho[] = {"ho"};
    typedef struct Hi {char str[3];} Hi;
    Hi yo = {"yo"};
    Hi eh = {{"eh"}};

    Hi no = {hi}; // #a

error: initialization of 'char' from 'char *' makes integer
       from pointer without a cast [-Werror=int-conversion]
Here, we want #a to have the same semantics as Hi yo = {"yo"};
with an array value accepted in place of a string literal char array.

C appears more lenient than C++ in what is currently accepted here 
(#a is accepted with a warning in gcc and clang, without e.g. -pedantic).

Specifically, can we specify the desired no-decay and array copy for #a ?