I agree, it would be best to keep this on the ui-side.
It occurred to me that the existing tree-style pijul branches ui could be enhanced to support the spontaneous workflow while still supporting different stances on which patches belong to a branch.
pijul fork with a filter could fork to a new branch containing only: repo origin + patches matching the filter + those patches’ dependencies. In other words, a partial fork.
Of course, users would usually want to work out of a full fork.
pijul record could accept a branch or branches as an argument so that one would not need to work directly inside a partial fork. Upon recording to another branch than the working copy, dependencies would have to be applied to the other branch as well.
pijul fork would effectively create that metadata, in other words, it would create a branch. The branch name would be the metadata. Pushing, pulling, and unrecording between branches effectively shuffles that metadata around.
With at least some ui enhancements to pijul checkout, merging branches could support the spontaneity of picking multiple filters if pijul checkout could accept more than one branch as an argument.
Just a brainstorm for now.