The problem is that the same action is used for different things.
What I meant was short-click detection just makes the entry point to the programming state less ambiguous (which you described as a problem). A "short-click" is just a practical timed cut-off for each click before the code resets the count var, not anything to be measured time-wise. I don't mean to change the general paradigms discussed.
So, IOW what I proposed is still:
1. select mode you want to re-program
2. signal 6 shortclicks to enter programming
3. click through mode options just like any other mode light and stop on the one you want
4. signal 6 shortclicks to set and exit
Same as before, but you won't enter 2 as easily by accident which I agree is possible with the existing way count is done. The problem with the above might be that 4 needs to be disambiguated from possibly clicking through the modes quickly in 3. Should this be a problem, perhaps replace "6 shortclicks" with some other sequence (short-long-short?), but make it the same sequence so the user has to remember just one special signal to program the light.
To summarize, I think this minimizes the principles the user has to remember. It's basically down to:
2 states, general use state, and programming state
1 signal to enter or exit programming state
click to move to next light mode.
That's all they have to know, more or less.
The main challenge is a signal that is unambiguous, not impossible to tap out, and allows us to know which mode they were in before they started signaling.
If anything above doesn't make sense, please feel free to PM me and we chat over IM or something.
---
So I suppose step-through debugging works well with your tools? I can't imagine trying to write that program without it, especially with printf's in morse. :)