Logically, your forced-on and motion timers are doing the same thing - setting an OFF directive in the future. So at first glance, they could be the same timer, just set up with different initial time of run.
But the problem arises when you get a motion trigger while a timer is already running. You’d probably want to extend the time (wouldn’t you?) - but you cannot discover what the remaining time is. You might replace an existing long time with a shorter one, which I imagine is unwanted.
There are ways round that by using an additional variable with the target datestamp, so you can see if the proposed new time is later than the existing one. Quite a bit of work though, it’s probably easier to maintain two separate timers I think.
The third timer has a different function, and you need to “know” from outside that it is there to block motion triggers. The only way to do that is by giving it a different name.
So I think your three timer solution is reasonable.
I’ve wrestled with this sort of problem myself, and ended up with a different approach. Putting the ON time into an accessible minute counter, with rules to decrement it and turn something OFF at zero.
That allows rules to compare a proposed runtime with actual, and if required overload the counter.
That still doesn’t solve the forced-off / blocking task though.
In my case I can detect when people use wall switches, and wanted to lockout any motion triggers for a period after they’d used wall switches (on the assumption that live user knows best).
So associated with each Lighting Item is (yet another) Item to act as manual flag. That locks out motion triggers when set, and I use the expire binding to time them out after a fixed period, restoring auto control.