Idea: Activities as Templates

I have classes of activity that I do every day where the desirable buffer configuration is predictable for all instances of the activity. Each activity corresponds roughly to one JIRA. For workflow/procedural reasons, it is often most efficient for me to have several such activities in flight simultaneously and to be able to switch between them as feedback comes in/builds/deployments finish, etc. What is unpredictable day-to-day is how many such activities I will end up juggling at any one time.

Given the current design of activities.el, one potential solution would be to simply define multiple identical activities, just giving them ordered names (e.g. taskA, taskB, taskC or task1, task2, task3) and then calling them up in order as I have a need. However, apart from being inefficient at the point of definition, in the interests of being generically usable, I can't give these activities descriptive names. If I have to exit Emacs and later I need to resume work on these tasks, I have to try to remember which is which. If I have to shelve certain tasks and shift to a different set of tasks entirely (not at all uncommon), then I either have to make additional task definitions to make up the difference, or else revert existing ones to their default state and lose the convenience of being able to pick up where I left off when I do have the opportunity to return to the previous tasks.

My proposal is to enable using an activity as a kind of 'template' (or, if you prefer, 'parent') which can be used to spawn instances that have their own names. This provides for an arbitrary number of tasks of identical procedural form, suitable for this simultaneous work scenario. Rather than having it be a different type of activity definition, perhaps this could be implemented through a new function, say, `activity-spawn` that clones the activity definition and prompts you for a new name for this clone, then creates the appropriate frame/tab for the clone. The clone functions like a fully-fledged activity for its lifecycle, supporting reversion, suspension, resumption, etc. When you're done with it, you discard it without any effect on the template/parent.