What do you need help with?

I decided to finally fulfill what I said in #2306 (comment) and turn lists into settings where possible and after copypasting the parser for sets I noticed that changing the type of settings is a breaking api change. The options I see are

1. Just do it. This would be binary incompatible for every use (except reflection with dynamic type detection for e.g. a gui) and source incompatible for almost every use.
2. Use ImmutableSet.asList for list settings. It has the same performance characteristics as the underlying set, ImmutableSets preserve the order of their elements and there is currently (not future proof) not setting where duplicate entries have any meaning.
3. Use 2. but make it a special case with a predicate like for the logger settings. Everyone wanting to do it correctly needs to check in addition to the setting type when creating a new value (everyone using the type as some sort of key will hate it).
4. Don't change the settings at all, just change the type when copying them (only applicable for allowBreakAnyway in CalculationContext). This option almost equivalent to not changing anything.

Should I go for the breaking change, use one of the slightly hacky solutions or just don't do it (would still create a pr to switch to ImmutableList rather than ArrayList)?

Final checklist

• I know how to properly use check boxes
• I have not used any OwO's or UwU's in this issue and have not removed those that were already there.

Wen't for the only proper non-breaking solution. See #3539