Description
Opening an issue to track #31563 again. Summary below.
The problem
In #31563, a proposal was made to introduce AbstractWrappedArray, a new entry in the type hierarchy of array wrappers. This would make it easier for packages like GPUArrays.jl or CUDA.jl to identify, say, whether a wrapped array contains a GPU array, and thus need to be passed to a GPU kernel. It avoids having to define many methods, one for each possible combination of wrapped arrays (which often leads to expensive and highly ambiguous methods) in order to avoid the AbstractArray fallback.
Current solution
The issue was closed by @vtjnash, referencing @dkarrasch's recent work on reworking the mul! and ldiv! functionality implemented in Base. That work basically made it so that Base unpeels the wrappers, and defines an interface to override that only takes the base array. That fixes the problem, but only for a handful of operations. #48861 is something similar, in that it reimplements said methods using traits that are easier to override.
Why that isn't sufficient
The fact that mul! and ldiv! now works better is great, but I we still need a principled approach to this problem that covers other operations and other array wrappers. We frequently get complaints/issues by users of GPU packages how some random array operation that we've implemented in CUDA.jl or so all of a sudden triggers the AbstractArray fallback when invoked using some random array wrapper.
cc @KlausC