It's possible, but every single piece of code that changes the settings with custom logic (that produces side effects, such as changing some Canon setting or installing some hook) has to be refactored; dmilligan already provided the backend and
some proof of concept code for a few settings.
The idea is to call the same custom logic code from both menu (where it's currently used, as MENU_SELECT_FUNC's) and config file switching. Currently, the custom logic is called only when changing that setting from menu, but not when loading it from the config file.
Refactoring all of this would touch the entire codebase. It probably can be done one menu item at a time, but I would not do this sort of refactoring without a solid testing framework (as it's very easy to introduce subtle bugs, and manual testing would be extremely time-consuming). That framework can be built on top of QEMU, on those models that can run Canon GUI.
I'm afraid I do not have the time and resources to implement this alone, but I do recognize the usefulness.
An easy coding task in this direction would be to add a simple testing script for QEMU, along
this idea. For example, a menu walkthrough (highlighting the differences between two ML versions).
If you cannot code, you can test the PR, and report what exactly you have tested. That's very helpful too.
you may wish to look at my toggler script
The script approach avoids the issue, as the menu API in Lua effectively simulates a menu interaction (so it calls the MENU_SELECT_FUNC's). So, for now, it's the only valid way to address this on the existing codebase. Be sure to use the lua_fix experimental build if you decide to go this route.
The approach (in the menu backend, not in garry's script) is a ugly hack though, and not a widely tested code path (other than
api_test.lua); dmilligan's approach is the right way to solve this, so I'm tempted to revisit it.
