I think this feature is reasonable, but I don't like doing this with an interface because these things won't work:

First, there's no way to configure the datasource object. Some datasources are configurable, usually with setParameters(). For example, the PhabricatorProjectDatasource takes a mustHaveColumns parameter to return only projects with workboards. Written like this, it's impossible to add "Projects With Workboards" to the quicksearch unless you copy/paste the datasource and hard-code the parameters you want. Obviously, this example is not likely to arise in practice, but other datasources (now or in the future) may reasonably benefit from configuration in quicksearch. (I suspect parameters may not currently be passed properly to Composite datasources, but we could resolve that later.)

Second, there's no way for a source to disable itself based on configuration.

Third, there's no way to add an upstream source which we have decided does not make sense in the quicksearch. For example, if you want Nuance Queues to appear, you have to copy/paste the whole NuanceQueueDatasource.

I think we can address these with a QuickSearchEngine and then a QuickSearchEngineExtension class tree instead. The EngineExtension classes would have a method like this:

public function newQuickSearchDatasources() {
  return array( ... );
}

That would solve setting datasource parameters, adding or removing sources based on configuration, and adding upstream sources.

Additionally, these classes could later be made responsible for the closely related logic in PhabricatorJumpNavHandler, which should also be modularized at some point.