I think I'd use defaultGuiHandler
That would not work very well because gui_init() would fail to initialize the gui mode.
Yeah, that makes sense, I didn't think through the if mode == current mode logic.
Or adjust gui_set_mode to deal with null old_mode.
I tried that first and failed due to my insufficient knowledge about the inner workings of the CHDK GUI. Also, any change there would lead to an increase in core size.
Using &altGuiHandler as initial value of that pointer would mean no increase in core size. This does not mean CHDK would start in ALT mode, that struct would only provide values that (IMO) allow a successful transition to default GUI mode.
I don't think I see any related glitches on the M100.
Currently, the first few words at address zero are used as initial value when members of that struct are accessed.
If it works, that's good enough for me. It should be better than the current behavior. My initial reaction was that I'd prefer not to have it initialized in an inconsistent state (that is gui_mode is "alt" but various other gui and alt state variables initialized as non-alt).
FWIW, I'm not at all concerned about increasing core size by a few hundreds of bytes if it makes things clearer or easier to maintain.
One thing that might thinking about more is if any of the gui_mode stuff might be accessed in other tasks before gui_init is run, since that happens quite late after the filesystem is ready and CHDK settings have been initialized.
The fact that your solution works on M100 suggests it isn't on that camera. One possible exception is cameras with touch screen support (n, ixus310, ixus240) which reference it in the touch task. I doubt your change will hurt those, but it would probably be better to have chdk_process_touch immediately return if gui_init hasn't run yet. I don't think this needs to be done to check your change in.
Startup scripts are run from spytask after gui_init, so they shouldn't be a concern.