I think we initially talked about this, but somehow it got lost, or maybe we/you decided against it after all.
The thing is that there are several other modules, like Search API Saved Searches and Search API Autocomplete, which need a mechanism to find out about the different searches/search pages that exist for a given index (or in general). So I think it would be greatly benefitial for these modules to move some of this search page discovery mechanism from Facets into the Search API.
My plan here would be to have a "Search page" (or a better name, if someone comes up with one) plugin in the Search API, with a few search-specific methods like
getResults() (with the option to execute the search if the results aren't there (yet)) and even
An implementation with a deriver to produce plugins for every Views page would of course be in the Search API, and you'd just have to change the code to have only a single class for all Search API facet sources, using that Search API plugin, and having a deriver that creates one facet source for every search page.
The large advantage for everyone would be larger adoption, since this would then live directly in the Search API, and other modules would be even more inclined to implement the plugin for their search pages. (I'd also be thinking about a
supportsFeature() mechanism, like for backend plugins – that way, there would be a clear way of implementing support for things like Autocomplete, which needs specific search-specific support. However, it doesn't seem to me like your code actually needs that – just the generic information cited above, as far as I can see.)
Would you be willing to make such a change?
I think it would be quite easy, just the normal boilerplate code to write for a new plugin type, but other than that pretty clean. However, it would of course again be a disruption in compatibility, so it would be a change that should happen sooner rather than later.
(Also, completely unrelatedly, I think this project needs a few more issue queue "Components" – "Search API integration", "Core Search integration", and maybe others. Having not just the default four will surely be helpful in the long term, when the module and its usage grow.)