The cat is out of the bag, the question is what to do about it now, and I proposed badges (see my new proposal below, which is not mutually exclusive with it):
The problem is you could have been aware of the problem and made legal code with it (for all arrays), but then the assumptions broke with the OffsetArrays package (and Julia 1.4). And now all who use the macro (or even if not, just take in AbstractArray or AbstractVector) will need to think about its use (and test for it) too. I’m not sure people will, that seems to be the fatal flaw for renaming to @unsafe_inbounds, with many people only taking regular 1-based arrays into account.
You really want to support AbstractArray for other reasons, e.g. sparse, Vandemonde matrices or whatever, and most of those alternative array types are still 1-based, but different storage formats.
OffsetArray is a different kind, orthogonal to the other alternative arrays, can e.g. be combined with Vandermonde.
I’m thinking could we solve this problem by introducing a different abstract array type in the hierarchy?
Had we done from the start (not too late?) problem averted:
abstract type AbstractArbitraryArray <: Any end
abstract type AbstractArray <: AbstractArbitraryArray end # would in this
proposal disallow non-1-based
const AbstractAArray = AbstractArbitraryArray # maybe good to have, as short indicating OffsetArrays ok