There are multiple frameworks dealing with the search space:

• Contact Query BAO / Advanced Search / Search Builder
  • Note: Profile is used as a storage model for the selection of fields from Contact BAO Query
  • Note: Smart Groups use a Contact Query BAO criteria as a storage model for the search
• Custom Search
  • Note: Custom Search extends the frontend/controller system from Advanced Search but it completely replaces the underlying search-mechanism. This gives access to some functionality (like Smart Groups) but not other (like customizing columns via Profile).
• Other QuickForm/Selector Searches (Find Activities; Find Contributions)
• Export
  • Note: Import/Export Mappings are used as a storage model for the selection of fields from Export. These are similar to Profile, except they include support for traversing relations.
• CiviReport
• APIv3/ APIv4 / API Explorer
• SQL Tasks

To some extent, there are distinctive features in each of these areas. However, I find it questionable that these distinctive features are enough to merit the separate subsystems. Example:

• The traditional Export subsystem is built on the Query BAO and other QuickForm Selectors. But it's not used for reports.
• The report subsystem doesn't integrate the standard contact tasks. Arguably, this is because many reports deal with different record-types. However, one could reasonably expose search tasks in a reported -- provided you match on the type of the record in each row.
• One can figure out how to run a quirky search using either CiviReport or the API. But if one wants to use that same search to define a smart-group, it wouldn't work.
• If you're reading the civicrm_saved_search behind a Smart Group, it's difficult to find documentation/explanations for the semantics of those fields.
• There are code-generators for some things (like API entities and API actions and Reports) but not others (like Search Tasks)

A couple example opinions:

• I like APIvX.get as a layer for defining query-backend. The main gap in using it as the backend for all the above subsystems is the lack of aggregate/group functionality.
• A search-task is basically an APIvX action plus (1) a bespoke form for tweaking the inputs of the action and (2) a declaration/registration of when to display the search-task.

It's not clear that a total convergence is sensible, and this one Gitlab issue shouldn't be responsible for every detail, but it makes sense to have some space to record general/broad discussion about the convergence of these subsystems.