Qukeys support for same-hand/location-specific inactivation

[SiriusStarr]

Is your feature request related to a problem? Please describe.

HRMs (home row mods) are a fairly common feature of layouts in the ergo keyboard community, especially for users who need to minimize lateral thumb movement. With the current implementation of Qukeys, they are prone to frequent misfires with quick rolls of e.g. adjacent home row keys (which are a common feature of many alpha layouts).

Describe the solution you'd like

Both QMK (via a userspace solution, achordion being the best known) and ZMK (via hold-key-trigger-positions) allow the user to customize, for any given qukey, a set of keys that it could possibly act as the hold value for versus always acting as a tap. Most commonly, this is used to make HRMs only apply cross-hand (i.e. a right hand qukey always resolves as tap for other right hand keys), but it can also be used for more detailed configuration (I personally disable my dual-function keys for same-row presses on the same hand only).

Describe alternatives you've considered

There isn't much alternative currently feasible in Kaleidoscope, other than learning to type "cleaner", but this necessarily becomes a problem at high speeds.

Configuration thoughts

At its simplest, this could simply be a flag to disable same-hand interaction; that would get a large portion of the functionality of this feature for minimum effort.

However, as mentioned above, sometimes more granular control is desirable, in which case, there are two possible approaches I can think of:

• When defining a qukey, one can optionally pass a list of secondary key coordinates for which it is active. IMO, coordinates make the most sense here, rather than key codes since you generally care about the physical relation of the keys. This is how ZMK does it and feels more "kaleidoscope-y" to me.
• Have a function that is passed the details of the qukey and secondary keys for each interaction, the return value of which determines whether the qukey can be active or not. This is how achordion works for QMK, but to me doesn't feel like a "kaleidoscope-y" solution, since it tends to prefer customizing plugin behavior rather than hacking on a process_record and the like.

[EvyBongers]

I'd love to have this feature! I'm not quite sure what will be needed to properly implement this. @obra recently mentioned on Discord that he is thinking of redesigning part of the API to have more flexibility going forward. It might be a good idea to write out use cases and expected behaviour so that this can be included in the redesign. I'll leave it to @obra to ask for specifics.