Multiple "actions" per workflow

Currently I think ComfyUI supports only one group of input/output per graph. I want to be able to run multiple different scenarios per workflow. For example there's a preview image node, I'd like to be able to press a button an get a quick sample of the current prompt. Then a separate button triggers the longer image generation at full resolution. And that's without manually disconnecting any nodes in the litegraph instance

Another scenario is manually selecting an image out of a batch and running only an upscale part of the highres workflow separate from the two-step process. First there's a way to choose the image you want, which sends it to the latent node, then another button to run step 2. For that case those two parts of the graph are totally disconnected from each other, or alternatively the image output is connected to the highres input somehow but execution doesn't proceed until you press a second button for that part of the workflow

I've also noticed, some people want a global seed node across all sampler nodes. So for this case it's a single number node that copies its value into the samplers it's connected to when a button is pressed

Some programming environments like Max/MSP solve this with "bangs" and input ports. It lets you send a string message like `set index 1 foo` into a special input port that interprets the command and sets the value of the widget. Can help if the action is entirely in the frontend. As for backend maybe the ability to tag nodes as belonging to certain actions and sending an argument to the prompt executor to only run certain nodes in a tag whitelist. In Max all nodes have special properties attached that controls their behavior and appearance, similar to UI designer properties in an IDE

I can see ComfyUI supplying its own set of hooks for lifecycle events like prompt being queued, that generalizes the seed randomization behavior that's a bit hard coded right now. Queuing a prompt would send a "bang" from some "system output node" that you can feed into the seed node, which triggers setting the new seed

Of course this is basically half of what Max/MSP does already but it's worth looking at how they solve these kinds of problems with their own node-based environment