P0388R4 was accepted into c++20 (and GCC already has an implementation);
Permit conversions to arrays of unknown bound
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0388r4.html
(I'm told that there was discussion of similar topics on the reflector but
don't have a link).

Following discussion on cpplang slack #future_standard there's some
consensus that:
static_cast should be allowed from a converted array of unknown bound to
the actual array type of the referenced object.

I believe that this should be treated as an issue for DR or quick fix in
C++20.

For example P0388 allows: https://godbolt.org/z/9BnML5

    using intu = int[];
    intu&& iurr = intu{1,2,3,4};

Now decltype(iurr) is int(&&)[] while the RHS decltype(intu{1,2,3,4}) is
 int[4]

So iurr is now a lifetime-extended reference, of 'size-erased' type
int(&&)[], to an object of type int[4]
The type of the actual referenced object is now lost to the program - there
is no way to retrieve it.

What should be the result of a static_cast to the actual type of the
referenced object?

    static_cast<int(&&)[4]>(iurr);

(Evaluating this static_cast crashes GCC trunk - see the code link above.)
It appears that current wording doesn't allow this static_cast but it seems
that it should be allowed

> if you can implicitly convert X to Y, it's a longstanding tradition that
> you can static_cast Y to X


The extra wrinkle here is...
Q: Do you allow static_cast of T(&)[] to any bound or just the bound of the
actual referenced object?
A: The static_cast should only succeed if the target type is the type of
the actual referenced object.
(anything else would be UB)

Postscript:
Assuming that the static_cast is allowed, and will SFINAE-fail for wrong
target type (i.e. wrong bound)
then there's a long-winded way to retrieve the bound by SFINAE trials on
all sizes 0,1,2....