Right now triggers use several different systems that are very similar but use slightly different infrastructure, which could be combined into one common system, thus reducing code complexity. These are the multiple ways that triggers which run every update are handled.

1. Originally the only triggers that run every update were the cooked controls (lock steering, lock throttle, etc).
   These triggers used a system for the CPU to re-insert them every update unless they were still running from a previous update.

2. Then we had triggers like WHEN and ON, which also run every update. and were piggybacked onto the same system, but slightly differently. They use OpcodeReturn to re-insert themselves whenever they exit.

3. Then we added user-definable Delegate callbacks, some of which can be called by other places in our C# code other than the CPU. These use a different system that allows us to schedule the callback to occur later, then lets the CPU execute it, then detects that it is done on a future Unity update and picks up the resulting value and uses it, then reschedules another call to the Delegate and does it again.

It is possible to actually collapse all these systems together to all use technique (3). We could make, for example, a RecurringTriggerManager object that schedules executions of the When's and On's, waits to see if they're all done, then schedules calls to them again if they are. We could make the SteeringManager do the same thing for the lock steering and lock throttle and so on triggers.

What this would buy us is a simplification of some of the weird logic in the CPU and in OpcodeReturn that's there to allow some triggers to respawn themselves and other triggers not to. This weird logic also handles trying to make sure that recurring triggers don't recur fast enough to prevent non-trigger code from ever executing.

With this change, all triggers would be one-shot triggers and it would be up to the SteeringManager and/or RecurringTriggerManager to decide to keep scheduling new calls to the one-shot triggers when it sees the old ones finished, rather than that being the job of the CPU to do in its ContinueExecution() logic, or the OpcodeReturn checking if the trigger returns true.

However, as a refactor it has the potential to accidentally invoke places in the code that still expect things to work the old way. It would have to be carefully checked to ensure everything had switched over. It's a case where after the switch the system would be cleaner, but making that switch could be hairy.

I'm not sure if I want to do this yet, but in case I do, this issue is here as a placeholder for it. At any rate it's the sort of refactor that shouldn't be attached to anything else (no other bug fixes, no other enhancements) so it can be done as cleanly as possible.