I would say that you load in the workflow file (which would create the new project) - similar to an attribute template. Then the workflow file would be copied into the project directory and get loaded when the project is loaded. Without the workflow the user would see all of the native operators provided by the sessions that get loaded in.
the set of plugins that modelbuilder should load by default;
the workflow task graph (which does not exist yet), which will definitely want to change the preferred order of operations if not also the list of “approved” operations; and
affinities between operations and workflow tasks (so that not only the first operation listed, but the order of all viable operations can depend on the selection).
When it comes to using an existing operation in multiple ways (e.g., turning polygon-session’s create edge into both create river and create road), we’ve discussed simply subclassing the operation. But what about relabeling an operation’s items? Overriding an item’s description (brief or detailed)? Hiding items? Marking items as advanced? All of these things are currently stored in the attribute system but arguably belong in “view” instead so that we don’t have to maintain multiple copies of the operator’s XML/JSON specification.
What if you’re editing an operation’s parameters and change the application selection? Should the operation edits be abandoned (this seems wrong and anyway, edits that don’t invalidate the operator will be preserved in the attribute collection for the operator).
How should we deal with “operator stay” functionality — where a user wants to re-run an operation multiple times, with or without parameter edits?