There isn't a sane return-value for charge() … and there really shouldn't be

[ELLIOTTCABLE]

At the moment, I think stage() and charge() are the only two aliens that re-stage the caller, but don't have a meaningful result to provide. The former case is another discussion to have (and not one that I'm remotely sure is ‘fixable’), but the latter one is just silly.

The only reason charge()ing an execution with responsibility involves also proceeding with evaluation, is that I've (probably mistakenly) tied the responsibility-management system in with the combination-evaluation system.

So, I posit we generalize the reactor, and allow it to preform multiple types of operations from a single queue. The queue would still be locked, by executions themselves as keys, which I'm pretty sure matches current semantics (that is, if there's an entry in the queue to ‘charge Xec with Obj’ that can't be fulfilled because the mask for Obj is conflicted, then subsequent stagings in the queue of that Xec are precluded as well), but also means that that ‘charge’ instruction waiting in the queue doesn't necessitate a frivolous advancement of the execution in question.