Last updated March 16, 2011.

Drupal 7 is not out yet, and Drupal 8 is just a far-away dream, but I'm thinking about what we'd like to see in the core Search module for Drupal 8 and beyond, so that we can get started on it sooner rather than having things get postponed again. So, here are thoughts from jhodgdon (and whoever else edits this page) about what would be good to see in a future Search module. With links to issues where available.

Structure/architecture of code, interfaces with other modules, etc.

In general, I think that the search module needs to be made more modular, so that various bits of it can be turned on, turned off, and replaced. A start has been made in:
http://drupal.org/project/search_api

Here are some more specific suggestions.

Make the way Search uses the form and menu system more standard
As things are now, the way Search uses the form system and the menu/tab system is non-standard, and it tends to make things rather difficult. For instance, there is no clear distinction in the URLs between search tabs/modules and search terms (e.g. path search/foo could mean you are searching for "foo" or that you are using the "foo" tab). This has led to many issues that we had to fix in Drupal 7.

I am not sure how to fix all of this, but I think it should definitely be fixed. Maybe by scrapping the idea of each search module being a tab, and instead using radio buttons, and using the standard form submit mechanisms of Drupal? It needs some thought. Here are some Drupal 8 feature request issues on the subject:
#753996: [META] Re-architect use of menus, tabs, and forms in Search module
#894486: Use the query string for search keys rather than appending them to the URL

Decouple from user and node modules
Right now, the code for search.module has a few places in it that pretty much assume that node.module searching is turned on and should be the default search. Also, both node.module and search.module have several places that support search.module. It would be better if search.module was truly independent of both user.module and node.module, and if all of the searching capabilities of node.module and user.module were in separate modules. Issues related to this:
#237748: Decouple core search module implementations from node and user module (and turn search/node and search/user to views).
#248154: Allow UI to choose which search module is default tab
Preprocessing
When both indexing and searching, there is some preprocessing that takes place. For instance, text has to be split into words, which right now has some implicit assumptions that make supporting other languages difficult (such as that a space separates words, which isn't necessarily true in Chinese and other character-based languages). Also, there is an API for third-party preprocessing that lets you install stemming modules.
There are several problems with the current approach:
Probably the best way to implement this is to have a hook_search_preprocess_info() that will let modules define their preprocessing steps. Return value could be an array with components 'languages' (define which languages this applies to), 'name' (human-readable name), 'process callback' (define which function to call to pre-process text), 'excerpt callback' (define a function to call to do excerpts, and this needs to be thought out a bit, but I have an example of how this could work in contrib project Search by Page, which is implemented in Porter Stemmer, and works).
Then the UI could let you make a sequence of preprocessing steps, turn each step on or off, etc.
Another implementation possibility would be to use a filter chain:
#257007: Convert hook_search_preprocess() into a plugin
Multiple tabs per module
Right now, search.module allows third-party modules to define search types, each one shown on a tab. But it only allows each third-party module to define one search type, which is very limiting.
#239133: Multiple Search Tabs Per Module
Pluggable index and retrieval
It would be great if the parts of search.module that actually do the indexing and retrieval were made more modular. Then you could easily replace the search module's indexing capabilities (with something like solr), or even replace it on a search tab by search tab basis (for instance, the user module already does its own thing for searching, but maybe for each tab, you could choose the indexing method?).
#282192: Pull custom search indexing into backend
Refactor the search query extender
Suggestions for improving the search query extender:
#582938: Fix up documentation and member names in SearchQuery
Ranking
Ranking seems to be somewhat more modular in Drupal 7 than it was in Drupal 6, but it could still be improved:
Other miscellaneous structure suggestions

User experience and user interface

Here are some additional suggestions that are more along the lines of user interface and user experience (although some of the structural suggestions above affect UI and UX as well).

More configuration options and other changes to node searching
Add more search types
More configurable:
Miscellaneous/small changes

Comments

Hi,

I propose to exclude Search module from Drupal core and let Drupal authors to concentrate on really important core features and architecture. Search module is almost not used today because it is too much for simple sites and not enough for big sites.

1. Simple sites - they don't want to have their DB growing (hosting limitations) and want to keep price as low as possible. Search module will not index taxonomy pages and custom pages so we need to install something else ... this is too expensive for small sites. They prefer to pay $50 for embedding Google Search or similar widgets and forget about all problems.

2. Catalogues and e-commerce solutions. In most cases these sites prefer Facets approach. Having taxonomy pages not indexed becomes extremely critical. To build a normal catalogue site we need either facets, either search_api or external search mechanism (ApacheSolr) depending on site size.

3. High loaded B2B portals, community sites... external search (ApacheSolr) only!

So, core search module doesn't satisfy any of these groups. This is why I believe search functionality should not be in core at all. We have a few nice modules such as facets, search api and apachesolr - we need to have community to continue them.

Thanks.

----------------
Regards,
Ardas Group Inc. - Web site development, Drupal services, Software development, IT outsourcing.