The Factory plugin offers a menu constructed by the server from information each plugin provides. We consider how the menu might complement or interoperate with an expanding Plugin Catalog.
We will presume that the add before choice mechanism is satisfactory. The menu offers the default choices when no further instructions are included in a prompt. The server admin is ultimately responsible for the menu's offerings.
The server constructs the menu from metadata provided by installed plugins. An admin could conceivably edit each plugin's factory.json file to configure the menu but this seems unlikely and would not survive a reinstall.
The menu provides quick access to frequent choices and therefore serves the author. The author could expect some control of the choices and their organization in the menu.
# Bidding
Plugins could bid for space in the menu. The plugin could then select the highest bidders in each of the three menu categories when showMenu constructs the menu from data aggregated by the server. client 
server
A bid would be a number assigned by the plugin's author in the range of, say, 0.1 to 10, where 1 would be assumed when no bid is specified. The bids set by existing plugins would guide authors in selecting appropriate bids.
The menu logic could provide a 'more' option if there are any bidders that are not yet represented in the menu. The menu would then expand as required to show more choices. Bids less than 1 might require this interaction before showing in an otherwise clean menu.
# Preference
The plugin catalog or about plugin pages could offer a yes/no option to include the plugin in the factory menu.
Show this plugin in the Factory menu.
This would require persistent memory, possibly in the site status, or server side in the factory plugin, or even site forks of the plugin's about page.
This would have the advantage over bidding in that some sites would include a plugin because they intend to use it a lot while other would have the plugin install only to read content from other authors.