This applies to the Google API for situations where there are many (thousands of) hits in Web text searches.
When searching large text sources, typically books, the default display order of results of well used search terms A and B may list the hits with A and B close together in the text block, first.
But not always.
The engine employs other factors such as popularity, date of text, text size, scan date, meta info, and so on, so the output can appear "random", and a few of the A_close_to_B hits get shunted way down in the search results.
The purpose of this question is to address concerns the agents of search have, by way of intuition, the notion that (the first) two search arguments (A, B) are most likely to appear in the same sentence, or paragraph, of the target text block. Thus, can the search results pages show the "closest" arguments (A, B) on page 1, and successive results pages show hits according to the criteria of increasing argument (A, B) distance?
Text Block____________M (scalar)
More specifically, well-used search terms (can be a quoted phrase) A and B are desired as being scalar value m (less than M) characters away from each other in the text block. The smallest (nearest) of the m < M hits would be displayed in the list first, succeeded by others as m approaches M. Whether or not any results are displayed when m > M, may be considered as optional in the Advanced Search section.
All well and good, as a solution to the above scenario addresses a most of the above issues identified with ordered search results.
Introduce another term C, which can either be set as within M of A or B or both/neither. At greater cost to GUI and engine, also consider a new limit K of A and N of B.
When more search arguments D, E, ... etc. get added to the mix, it is more of a challenge to conceptualize the search page GUI with implementation of such an integration, especially when different relational limits K, N, O, ... etc. are on offer.
So applying just the one limit M to all terms will conceivably be part of the most practical solution.
The question points to the possibility of tailoring the API for this purpose- if not- it's out there for perhaps a development for even Google itself to consider, as Chrome evolves.