from #21717 (comment))

I'm -1 on this feature. The problem solved here can easily be solved by sorting the choices before passing them to the choices option (either with usort() or - better - in the database).

i figure the feature im seeking is a choice_order option.

I am not convinced we need this. The issue laid out in the initial description seems specific to some of the core types, isn't it? So solving the ordering there (as a bug fix) looks like the solution to me.

You're right, if we can do something for the core intl types that be great. Though i agree we probably dont want a generic choice_filter/order option. Solving it with choice_loader seems the better practice.

What about specific filter / order options for the intl types only?

Related to #11847 and #28624 then?

#11847 is solved by #28624 actually. But #28624 introduces a global choice_filter option, so perhaps something we don't want (as we've concluded here). Adding choice_filter only the intl choice types could work (i tend to believe a "callable" option is more powerful then a "list of values").

Another thing is (hence i've created this issue) the ordering of choices. If we use "group_by" we might need a different ordering to comply with the grouping (as demonstrated here with timezones)

So perhaps intl_filter + intl_order are the better options (tied to intl choice types).

Regarding your timezone example: Why would we want the choices to be ordered differently when they are grouped then without the grouping?

because for UX they should be ordered by GMT offset (from low to high)

But this order is fine for either case, isn't it?

not sure i understand, technically/semantically it doesnt matter (the same choices remain available)

however looking at

for UX the optgroups should go from ... -2, -1, 0, +1, +2, .... That's what im trying to solve now :)

The choice_order or choice_sort option for intl types only sounds good to me.