We should probably think about this in the context of my rework, as we really should design for trimability here.

The difficulty lies with the globalness of this method (it knows nothing about individual resolvers) while having to opt-in per resolver to get static trimability of not including all the array mappings.

Maybe we can do something clever with an interface on resolvers that support arrays to be able to pull out the WithArray resolver type (and replace the resolver in the list for the new 'WithArray' version).

At that point - as far as I understand - all implementations of that interface will get rooted, basically global opt-in with extra steps.

Yeah, probably the same thing applies for ranges etc.

Ranges are a bit different in the sense that they're not an automatically derived type. A range is its own type (and you can have an array of that range again). So you're right in the sense that we probably should rename EnableRanges to EnableBuiltinRanges given those are the ranges we'll start supporting.

Multiranges is probably the best analog to arrays as it's similarly automatically there, just only for range types. Those probably deserve the same cross-cutting opt-in treatment as arrays should ideally have :)

Yeah, built-in ranges are a very constrained set, whereas there's an array for every base type (and more), that's true.