As Aybe suggests in the comments above, I'd recommend separating the concept of Input from the concept of Actions. You can do this in your own scripts, even if you're not ready to jump into the new input system.
To do this, you'd have one script that manages reading the player's input devices and determining what actions have been performed. This has several benefits:
If one action should affect whether another can be performed (eg. taps & holds coexisting on the same button), you can coordinate the two in one place and ensure the correct one fires.
Your input logic is centralized. If you add control mapping, or need to swap out a whole new input handler (eg. for a new platform with completely different input hardware), you have one well-defined place to make these changes, rather than sprinkling them through every script that uses input.
Then your individual behaviour scripts can subscribe to this input controller for the actions they care about. A side benefit you get with this is that your in-game effects are now decoupled from their triggers: you can re-use those same behaviour scripts for non-player initiated actions, like NPC abilities, or events in cutscenes - substituting an AI controller or cutscene script as the action provider.
It's up to you how much knowledge your input controller script has about the player's various abilities. It could explicitly know all the action types it needs to support and their relationships, and expose getters / events / handler slots to fire off the corresponding behaviours. Then you control which action blocks which with explicit logic inside this script. Or it could be a completely generic input-checker that accepts subscription requests asking it to watch a particular input, and maybe a priority level or spillover setting to control which subscriptions should fire first / block other subscribers. Then it's delegated to the subscribers to describe the input they want and its conditions.