For example scarphin's case of a flag used in old C::B and in the new C::B version it is added to the list of flags? Would this still work?
What happens is: If you open a project all compiler flags are being parsed (they are a list of flags). If found in the "checkbox based" settings the checkbox is enabled and if a flag is not in that list its being put to "other options". So, what happens in this specific case of a compiler option being made "official" is that this flag is being applied in the UI, but its now in a different place - in the checklist box.
So nothing gets lost, its just being visualised differently.
I think the
only feasible way of handling this would be that in case we realise a difference between the checklist based and the other options we issue a warning asking what to do. The issue here is that you can use scripting (?) but at least macros in "other options" - so its not so easy to implement! And there is no automatism that will work reliable.
But if you decide to go for such a dialog - make it an annoying dialog. Because still: The overall goal is to use the checklist based list of compiler options in the first place and in case you don't find there what you are looking for use "other options" as a last resort.
If people just "copy and paste" from the internet w/o trying to understand what they are doing I don't know if its helpful
to them if we account for such laziness. Its a very bad thing to do in the end.