Switch doesn't engage/behave as a tap if its hold is a blank PP

[Promit]

Ok so this might be an engineering limitation or intentional behavior, I'm not sure. Here's a button scheme:

Now the question is, what should happen if PP #1 Hold is unassigned? The switch looks like a tap-only switch:

But it will behave as if there is a hold function - the tap action engages on the upstroke and a long press will do nothing at all. My position is that it should behave as a tap-only switch in this case.

 

[yek]

My position is that it should behave as a tap-only switch in this case.

Wouldn't say that this is a bug.

The button is programmed as a TAP+HOLD button so it performs as one.

If you want to make it operate as TAP only, change the HOLD function to "Unassigned".

Otherwise the FM3 must always perform an extra check: (1) is the button programmed as a TAP+HOLD button, (2) what's the HOLD function and it is valid.

 

[moerker]

I think the point is that this appears to be counter-intuitive:
Whereas the "normal" per-preset functions behave flawlessly in this context (and the FM3 has to check the function here, also), only the "unassigned" function (since it is a function, after all) is behaving differently. From the per-preset overwrite user point of view, this is not consistent behavior.
I get the point with the programmed TAP+HOLD, but (maybe I am wrong), since it appears that all per-preset functions are directly mapped to the tap or hold function, it "feels" broken.