A specific block of code running within a given context (state) is one piece of functionality.
That functionality can be triggered from all sorts of actions in the program.
It can be from a menu, a right click, a widget, hot-key, side-effect, etc.
The functionality is ‘complete’ and ‘consistent’ if and only if for all mediums where it might be triggered, it is triggerable and deterministic.
For example, there are 50 functions available in the menus, all of them can be triggered through a default hot key sequence, and all of the sequences can be rearranged. The set of available actions matches the two different entry points.
The tricky part is the implicit context.
If, say, as a result of a user action, one or more of the state variables is assigned as input to the functionality, then in higher global contexts, those assignments may no longer be applied.
For example, something is highlighted in an edit window, so it is passed into the functionality, but it is ignored by the global menu. Thus, the behavior of the hot key and the menu differ. Opps.
That is an inconsistency if the user does not expect it to be the case. From their perspective, they triggered the same function, and they expect the same results either way. The key is a shortcut to the menu, not its own interface paradigm.
In this way, the overall state of the application, the global state, is the one that users connect with. Any sort of localized state that behaves differently from that generally comes as a surprise. Surprises are not good. But it is easier for a programmer to write more localized code than it is for them to attach their work into that global context, so we see these types of violations frequently.
