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 her
e 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....