And there's the crux and there's the rub.

Perhaps at least some grease to the process could be applied by having a group that is allowed to apply approved patches. Many who are paying attention may immediately conclude that this does no good. But the point would be that gods would be very quick to approve patches where it is obvious that no security problems are being introduced while it is almost never trivial to quickly apply a patch because one must pretty thoroughly vet the patch and then must test whether the application of it actually broke something. So, once a patch is approved, a path applier could, when they had the time, decide that the patch is worth applying, apply it, test the results, and then revert the patch if needed. So that delegates what is often a non-trivial amount of work away from gods.

To complete some security details: Once a patch is approved, the author would no longer be allowed to modify the patch. When a patch applier applies an approved patch, the "current" patch is automatically approved. If there is no "current" patch, then the attempt to apply the patch is denied. Note that finding "the 'current' patch" involves scrolling through the most recently applied (few) patches until you find one that matches. Another possibility would be that modifying a patch unapproves it. But I would only allow that route for patches that have never been applied.

Note that denying the ability to modify something probably needs to be implemented within the canUpdateNode() system. Several previous attempts to deny the ability to modify have turned out to have loop holes if they didn't cause canUpdateNode() to return a false value (due to some poor security-related choices in the Everything codebase). But our new accessRule feature should make this easy to implement. And the "editing removes approval" feature is another likely place for a loop hole to appear. It would probably be better to allow the author to unapprove a node of theirs if it has never been applied (which would then allow them to edit it as a separate step).

On one minor technical point, there is no need to temporarily set $USER to -1. You just pass -1 (instead of $USER) to the updateNode() function.