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 *?