There are many discussions here concerning a lack of control of delay timers in automations. Certainly when a delay timer is implemented it must create some identifiable code construct in order for the timer expiration to return to the automation.
There are many suggestions to circumvent delay timer actions which seem overly complex to address what seems to be a simple but necessary function.
Consider an automation for a motion operated light which uses a delay to automatically switch a light off after being turned on due to motion. Now, I would like the light to be able to operate normally in cases where the light is physically or programmatically turned on, i.e. not turned off except again physically or programmatically. Considering that the light may be physically turned on within the period of the delay timer being motion activated, the light will now turn off as the delay timer expires rather than staying on as desired. The motion/light automation checks the condition that the light is already on and fails out before initiating the delay timer but if a delay timer is currently running, it would be handy to kill the timer.
Don't use a delay, do this instead: Motion activated lights automation
Also you can detect physical activation using this: How to use context