Problem

In #12019, we had a discussion about how to have an Open With menu item that opened a notebook with no kernel. Two main ideas were eventually discussed:

1. Creating and registering a new NotebookFactoryWidget which has different kernel starting behavior. However, this exposed that there seems to be some assumed dependencies, like the toolbar factory takes in the name of the factory, etc. We noted here that some things didn't work. It's possible we could just make a new plugin in notebook-extension that largely duplicates the existing notebook factory plugin, but just change the kernel start preference.
2. This approach: Separate out the initial kernel starting behavior from the widget factory by passing in a separate kernel preference along with the factory in the docmanager:open command. That particular PR involves manually modifying the "open with" menu from inside a plugin, which makes me uncomfortable, but I think the idea is good - the kernel start behavior should probably be orthogonal to the factory, with the factory containing a default behavior. This PR was merged into JLab 4.5.

The problems with (1) include:

• now there are two widget factories that are almost the same, except for this one starting behavior. If someone wants to modify the notebook widget (like add a toolbar button), they now need to actually modify two different notebook widget factories
• from memory, the kernel start behavior only affects the initial launching of the widget, so why do we encode it as widget state? It seems it should be naturally stored in the registry, but maybe not the widget itself (though I think it's probably too late to make a breaking change of removing this state from the widget - rather we can think of the widget kernel launch info as the default for the widget).

Proposed Solution

The one part of the second approach above that smells a bit to me is where the notebook extension explicitly modifies the "open with" menu. It feels like the logic populating the "open with" menu should be in one place, currently in the filebrowser. One way of institutionalizing this "another opener that has a different kernel start behavior" is to introduce the notion of widget factory registry aliases. For example, in the notebook extension, we could tell the widget factory that we have another "factory" that is the same as the notebook widget factory, but with some extra arguments to the open command (i.e., a different kernelPreference than the default). This sort of mirrors how we can register the same function for different commands, but just have the arguments change the behavior.

Thoughts?

Additional context