The documentation aspect is adequately solved with a comment ... radical notion, I know.
When this discussion comes up, a lot of the time I find that people fail to notice that there are very different cases. In the vast majority of cases, not only is the WHERE clause quite simple, but in all probability some attention has been paid to providing indexes for common queries and so the relationship between the query and a corresponding index is both simple and obvious. So much so, in fact, that even documenting the relationship is questionable unless one has an automated system for doing so (theme and variations on databasing COMPILE XREF data).
Thus, there are actually only a small percentage of queries where the relationship is even complex enough to be interesting. I think these fall into two categories, intentionally interesting and unintentionally interesting. The intentionally interesting category is the sort of thing one runs into in analytical reporting where one want to slice and dice the data in many and unpredictable ways. There are strategies for that sort of thing, but they need to be carefully considered on a case by case basis. This is a good domain for dynamic queries and one certainly doesn't want to be tying the hand of the engine there, but rather letting it fit the tool to the problem. This is also a good type of problem for some considered documentation to help the next person understand why a particular strategy has been used ... not just the index ... especially since requirements may change over time and the strategy may need to be adjusted.
Where things get interesting are the unintentionally complex cases. In many cases, this is a question of asking the wrong question. A really classic case of this is a database design which includes a company code or some such as the leading field on many indexes, but at a particular site there is only one company so someone writes a query which does not include the company code in the selection criteria. Presto, full table scan. Of course, USE-INDEX isn't going to help this any and what really needs to happen is intelligent thought about the query and its relation to database design. Sometimes, it turns out to be a limitation in the database design which is really at fault. E.g., a series of multi-component indexes are provided, but the combination of fields doesn't quite match the current case, perhaps because there is no selection on some relatively high component of the best index and thus no further bracketing. These are cases that can't be solved by USE-INDEX either ... one might make them slightly less horrid, but the real answer is to recognize that the universe of ways that one needs to get at the data is now larger than it was before and that the indexing strategy needs to change.