Bug 500967

If something has default shortcuts, those can be disabled rather than removed, yes. Non-default shortcuts can only be removed though. And for custom commands, since they by definition have no default shortcuts, they therefore inherit the "can only be deleted, not disabled" behavior. So I can see where the issue comes from with your use case.

The thing is, if we did add the functionality you're requesting, surely the "this is a pain in the ass" behavior would simply shift to the annoyance of having to disable and re-enable the shortcut. It wouldn't actually stop being a pain in the ass, right?

In general, since the shortcuts are global in scope, you want to avoid overlaps with apps' functionality. Generally that's accomplished by using modifier keys. In this case, maybe Meta+F10 would be a better shortcut? Is there a reason why that doesn't work for your use case?

(In reply to Nate Graham from comment #1)
> If something has default shortcuts, those can be disabled rather than
> removed, yes. Non-default shortcuts can only be removed though. And for
> custom commands, since they by definition have no default shortcuts, they
> therefore inherit the "can only be deleted, not disabled" behavior. So I can
> see where the issue comes from with your use case.
> 
> The thing is, if we did add the functionality you're requesting, surely the
> "this is a pain in the ass" behavior would simply shift to the annoyance of
> having to disable and re-enable the shortcut. It wouldn't actually stop
> being a pain in the ass, right?
> 
> In general, since the shortcuts are global in scope, you want to avoid
> overlaps with apps' functionality. Generally that's accomplished by using
> modifier keys. In this case, maybe Meta+F10 would be a better shortcut? Is
> there a reason why that doesn't work for your use case?

Hi Nate, thank you for your reply.
Indeed, the pain in the ass behaviour would shift to the need for enabling and disabling custom shortcuts, but the underlying issue that keycodes are intercepted and not forwarded to the active application is as far as I understand a fundamental core part of waylands  ̶d̶e̶g̶r̶a̶d̶a̶t̶i̶o̶n̶ ̶o̶f̶ ̶u̶s̶e̶r̶ ̶e̶x̶p̶e̶r̶i̶e̶n̶c̶e̶ security tenets, so that cannot be changed. It is still preferable (in my opinion) to be able to enable and disable custom shortcuts instead of having to keep track of custom shortcuts in a spreadsheet somewhere that is separate from the KDE settings.
The reason why Meta+F10 does not work for my case is twofold: 1) It's probably already bound to some default shortcut like "Switch to Workspace 10" and 2) I have a 65% keyboard that doesn't have a function-key row. Not only do I not have a Meta button on the right side of my keyboard, I also need to hit the Layer+ key to turn my Number-Row into the function row, and suddenly a 2-button shortcut is turned into a 3-button shortcut not unlike the 3-finger salute, just even more uncomfortable.

You are of course not obligated in any way to support custom keyboard layouts, this is just the reason why for me personally it doesn't work well.

Being able to disable a custom shortcut's keyboard shortcut (or maybe even the whole thing) makes sense, but I would still encourage you to seek out a different solution for your use case here, as even if we implement this, it sounds like the result will still be uncomfortable and annoying.

(In reply to Nate Graham from comment #3)
> Being able to disable a custom shortcut's keyboard shortcut (or maybe even
> the whole thing) makes sense, but I would still encourage you to seek out a
> different solution for your use case here, as even if we implement this, it
> sounds like the result will still be uncomfortable and annoying.

Agreed. In most cases users just want to set or unset a shortcut, not disable/enable custom shortcuts.

(In reply to insuna from comment #2)
> (In reply to Nate Graham from comment #1)
> > In this case, maybe Meta+F10 would be a better shortcut? Is
> > there a reason why that doesn't work for your use case?
> 
> The reason why Meta+F10 does not work for my case is twofold: 1) It's
> probably already bound to some default shortcut like "Switch to Workspace
> 10" and 2) I have a 65% keyboard that doesn't have a function-key row. Not
> only do I not have a Meta button on the right side of my keyboard, I also
> need to hit the Layer+ key to turn my Number-Row into the function row, and
> suddenly a 2-button shortcut is turned into a 3-button shortcut not unlike
> the 3-finger salute, just even more uncomfortable.

kmonad[0] may be a useful tool for your circumstances. It allows you to use ordinary keys as modifiers when held (e.g., I configured my z,x,c, to also act as ctrl, meta, and alt respectively, and similarly on the right).
If you are using a mechanical keyboard that supports QMK [1], that also provides this functionality (and more) at a firmware level.

[0]: https://github.com/kmonad/kmonad
[1]: https://github.com/qmk/qmk_firmware/tree/master

(In reply to Nate Graham from comment #3)
> Being able to disable a custom shortcut's keyboard shortcut (or maybe even
> the whole thing) makes sense, but I would still encourage you to seek out a
> different solution for your use case here, as even if we implement this, it
> sounds like the result will still be uncomfortable and annoying.

Then if disabling custom shortcuts, which would greatly alleviate the pain, is not possible: Is it feasible to add an option for the kde compositor to replay intercepted keycodes/shortcuts into the focused application? Similar to how `xdotool` used to work?