The different sources have a differing set of filter types. If you make a few selections for the filter categories on the d.o mock you'll notice when switching to the recipes source that the results section is empty even though no search query has been entered nor any filter setting was applied. if you proceed and switch to the drupal core source and again make two selections on the filter categories section which differs option wise from the d.o mock and then switch back to the d.o mock you will notice a change in the numbers of results on the d.o source tab. making no changes and switching back to the drupal core source the results change again in the tab (see filter.mp4).
so technically each of the three available sources has a different set of "filter category" options (recipes need a few initial) and probably each source would probably also need a different set other filters because it is not sure if maintenance, security and development status apply and or make sense at all for each of the three available sources.
it would make sense to keep the filter setting selection within the scope of a single source, and each of the sources has a default set of filter settings. the only exception might be if a developer deliberately decides and sets that their own private bespoke source should follow and adopt the set of filter types of another source for example the d.o mock.
Drop the results count in the tabs. in regards of the page order the search field, the corresponding filter settings and the results are underneath the tabs; visually and hierarchically the three components belong within a SINGLE source. to make sense that the search applies to ALL sources the search as well as the filter settings would have to be moved before/above the tabs. then the results count would make sense but as i said that way ALL source would have to have the same filter settings. and due to the diversity of source that is more or less impossible.
Totally agree. I think we originally assumed everything would have the same TYPES of filters, but not necessarily the same values inside (for example, recipes may have categories, development statues, maintenance status, etc - but they wouldn't have the SAME categories, even if they did).
So I think we have to do this.