I would change these and all similar lines to this:

UserOnToggle.Trigger(InterruptPriority.CallbackOnce, !guiCaused, new BooleanValue(pressed));

Implement UserDelegate.Trigger like this:

public TriggerInfo Trigger(InterruptPriority priority, bool immediate, params Structure[] args) =>
    CheckForDead(false) ? null : Cpu.AddTrigger(this, priority, Cpu.NextTriggerInstanceId, immediate, args);

Cpu.AddTrigger like this:

        public TriggerInfo AddTrigger(int triggerFunctionPointer, InterruptPriority priority, int instanceId, bool immediate, List<VariableScope> closure)
        {
            TriggerInfo triggerRef = new TriggerInfo(currentContext, triggerFunctionPointer, priority, instanceId, closure) {
                IsImmediateTrigger = immediate
            };
            currentContext.AddTrigger(triggerRef);
            return triggerRef;
        }

And finally ProgramContext.AddTrigger like this:

        public void AddTrigger(TriggerInfo trigger)
        {
            bool immediate = trigger.IsImmediateTrigger && trigger.Priority >= CurrentPriority;
            if (immediate)
                Triggers.Add(trigger)
            else if (! ContainsTrigger(trigger))
                TriggersToInsert.Add(trigger);
        }

The only thing I am not quite sure about is whether the check ContainsTrigger should be there for both or, as written above, for pending only. WinForms (and similar GUI toolkits) do not check such a thing and you have to do it manually in code (either use some flag or temporarily unsubscribe the callback), but that practice is so common, that I am tempted to make it a rule and always check, thus making it:

        public void AddTrigger(TriggerInfo trigger)
        {
            if (ContainsTrigger(trigger)) return;
            bool immediate = trigger.IsImmediateTrigger && trigger.Priority >= CurrentPriority;
            if (immediate)
                Triggers.Add(trigger)
            else 
                TriggersToInsert.Add(trigger);
        }

Reasoning for it all:

1. set button:pressed to true. from main should execute the callback immediatelly, but with elevated priority, that no other (non-immediate) callback can interrupt it (like click on other button).
2. set button:pressed to true. from recurring trigger should delay the execution after all top-priority triggers are finished.
3. set button:pressed to true or more common set editBox:text to "something" from inside the very callback that is handling the change, should, probably, do nothing. This is about the ContainsTrigger check.

P.S.: InterruptPriority.NoChange won't be a thing after this.

Myabe the check should rather be written like this:

        public void AddTrigger(TriggerInfo trigger)
        {
            bool immediate = trigger.IsImmediateTrigger && trigger.Priority >= CurrentPriority;
            if (immediate) {
                if (! Triggers.Contains(trigger)) Triggers.Add(trigger)
            } else if (! TriggersToInsert.Contains(trigger))
                TriggersToInsert.Add(trigger);
        }

Because

1. guiCaused callbacks happen asynchronously together with setting the property. You can execute set button:pressed to false, which would execute the callback, get interrupted by IPU, now you can click on the button but original won't schedule the callback now, althought you will now read the state as true and onTrigger never notified you about it. Ignoring current callback when scheduling pending should fix the situation.
2. Executing the callback immediately from inside itself is probably not desirable. Not a big deal, but rather prevention. It is quite common mistake WinForms starters forget about (that changing the text of edit box from inside OnTextChanged will call the handler recursively). I am still not 100% sure about it, as it could have some consequences I cannot see right now, but still think it is the better way to do it (prevent that recursion, even indirect if you change property of some other control that will in turn backfire at you changing the original property/attribute/suffix).

https://github.com/Dunbaratu/KOS-1/blob/3edfc4294cceb47876c11193e5e1db92760b0ede/src/kOS.Safe/Execution/CPU.cs#L1434

This looks like running triggers are removed from ProgramContext.Triggers an I assumed they are still there, until they exit/return. It would require third list for those triggers (that were removed from Triggers and didn't finish yet).

BTW: The if (trigger is NoDelegate) can never be true, the classes are not compatible.
https://github.com/Dunbaratu/KOS-1/blob/3edfc4294cceb47876c11193e5e1db92760b0ede/src/kOS.Safe/Execution/CPU.cs#L1390
I have already changed that in one of my PRs to if (trigger.EntryPoint < 0)

In OpcodeReturn, a new trigger is created when the old one returns. Triggers are removed entirely once they start executing, and the "return" from the code causes a new instance of the trigger to get constructed (a new structure pointing to the same entry point, same program context, etc) and put on the stack. This is done so that the infrastructure for handling recurring triggers was easily laid atop the already existing infrastructure for handling one-time triggers. It also ensures recurring triggers can't possibly re-interrupt when a trigger's code is already in the callstack, because its; the return at the end of the currently executing trigger subroutine that causes a new instance of the trigger to get put into the list, if the trigger is a recurring one. Until that return happens, there isn't even a trigger in the CPU's lists for it anymore.

The other reason for implementing all triggers as one-shots (with recurring ones being essentially one-shots that schedule a new instance of themselves as they return), is so that when a bit of C# code is querying the kerboscript program for something (i.e. like VecDraw:VECUPDATER does), it can treat each call as a single path from "scheulded" to "executing" to "finished and here's the answer" without having to handle what happens when that trigger is called again. (essentially THAT trigger isn't called again. A new one cloned from it is.)

I will leave that to your decision. The first version:

        public void AddTrigger(TriggerInfo trigger)
        {
            bool immediate = trigger.IsImmediateTrigger && trigger.Priority >= CurrentPriority;
            if (immediate)
                Triggers.Add(trigger)
            else if (! ContainsTrigger(trigger))
                TriggersToInsert.Add(trigger);
        }

fixes the first two points (callback from main or recurring trigger), but does nothing with the third (allowing recursion of callbacks).

I could have said that I am OK (not preferring but OK) with callbacks being executed inside recurring triggers without changing the priority, but I have definitely warned about immediate callbacks executed from main. Why not solve both at once, especially when I now see the code and that it is not so difficult to actually delay the callback when inside recurring trigger.

I am still not sure about the third point (prevent recursion) and it would obviously need more book-keeping (third list for running triggers - added here when removed from Triggers and removed from it in OpcodeReturn, probably). Then the check could be made like this:

        public void AddTrigger(TriggerInfo trigger)
        {
            bool immediate = trigger.IsImmediateTrigger && trigger.Priority >= CurrentPriority;
            if (immediate) {
                if (! RunningTriggers.Contains(trigger)) Triggers.Add(trigger)
            } else if (! ContainsTrigger(trigger))
                TriggersToInsert.Add(trigger);
        }

Assuming ContainsTrigger is unchanged (checking Triggers and TriggersToInsert as active triggers are still somehow pending, but passed the priority test, if I understand it correctly).
Maybe it should check for both RunningTriggers and Triggers when handling immediate. You know the infrastructure much better than me, you know I was not able to implement it.