I think a relevant factor is whether a flag change semantics in a relevant way.
For example, optional return type restrictions for abstract methods (#14377) are superficial. It only documents and ensures correct interface types, but enabling or disabling this flag won’t change the behaviour of a (correctly typed) program in any way.
Such a flag can always be enabled unless you know explicitly that it conflicts with a component that’s not compatible. The effect is very localized to implementations of IO::Buffered.
On the other hand, changes such as preview_overload_order can have significant effects on semantics anywhere in the entire program.
I don’t think this could even be scoped to shard locations because what would happen if overloads are defined in different locations?
I wouldn’t think so unless you wanted this specific grouping to be an edition?
My idea would be for editions to be based on the year and include an increasing amount of flags to be enabled.