Is it a good idea to support more than one set of candidates in a workspace?

[warpfork]

First of all, context review:

• A Workspace is a a dir containing a .timeless/ dir. It has a set of Catalogs (with release manifests which map "ModuleName:Version:Item" tuples to WareID for many Modules).
• Many Modules (denoted by a module.tl) file can exist in one Workspace.
• Every time you evaluate a Module, it produces a "candidate" release.
• Candidate releases are how we propagate WareIDs between Modules. We don't publish them; "candidate" is a temporary name, and can be referred to only in this local Workspace.
• We can accumulate candidate releases by evaluating several modules... and then choose to give them permanent names and publish them all at once. (This is our solution for being able to test upstream/downstream dependencies at all once, and release matching sets that are known to work.)

So, the question: Should we support more than one set of candidates per workspace?

Concretely, that would mean:

• if you run stellar emerge example.org/foomodule for a module, it'll produce a candidate release stored in the path $WORKSPACE/.timeless/candidates/default/example.org/foomodule/*.
• if you run stellar emerge --saga=try-dancing example.org/foomodule, it'll produce a candidate release stored in the path $WORKSPACE/.timeless/candidates/try-dancing/example.org/foomodule/*.
• all the (yet-to-be-written) stellar catalog release commands would similarly accept a --saga flag.

If we don't support this, everything would be the same; it would just skip a layer of directories.

This is mostly a question of UX. If we add this flag, will people actually find it useful? Is it possible to emulate the same behavior by just doing a fork of the Workspace -- and given that the answer is yes, is it going to be a better ergonomic experience overall if we simply tell people to do that, instead of building a special feature for this potentially rare user story?

[warpfork]

It's kind of a potentially weird feature because in addition to the fact you can satisfy the same needs via forking the workspace, there's another partial satisfaction as well: your experience even blowing away the candidates dir completely and regenerating it while switching back and forth the content of some modules will be pretty chill, because almost everything inside each major step of evaluation will memoize; only the module graph traversal itself would be recomputed, and those are pretty fast and trivial to re-run.

[warpfork]

Another reason I'm nervous to support multiple candidates sets is that the idea of supporting multiple catalogs turned out to be super unwise, and we just stripped it back out in the workspace rework (#4). But I'm not sure if these are going to turn out similar or not. Since there's by design no ability to publish or polinate around candidate releases, that shifts the complexity budget around pretty significantly.

[warpfork]

On the gripping hand: there's a strong "Porque no?" argument to be made in favor of implementing this, since I already implemented a SagaName concept during the first pass on the candidates system and threaded it all the way through. It's just the flag that's missing from the main methods at this point.

And it seems like the amount of complexity that support for multiple candidate sets would add for a user who isn't interested in them should be near zero: they just always experience the saga="default" path and everything just works.

So unless we can come up with reasons that this is an anti-feature, I'll probably default to doing it.