A ReverseIndex is really easy to maintain. Any page you come across that needs a reverse index, just add the link target. If you only have access to the current page but not the master index, this is also ideal as individuals can create the index independently of each other. Nonetheless, for the reader, the index is just the results from a search. There is no added order, no organization, no explanation of the links. It may return extra results too if the search is not tight; this behaviour is sometimes called greedy. In this way, a ReverseIndex is writer-oriented. Contrast this with a ForwardIndex.
A ReverseIndex gives the categorisation decision to the author of the content page, rather than the author of the category page; this property is sometimes called lazy as it pushes the decision to the last leg. Typically this is a good thing, as the content author knows more about the topic. However, this can cause inconsistencies in decisions on what should be placed in what category. For example, the writers of BillClinton, RonaldReagan, JacquesChirac, GeorgeBush, and FloridaRecount might all have different ideas about what is meant by the "president" category: current presidents, ex-presidents, or presidential topics? Conversely, a ForwardIndex can be better since people are more used to thinking in forward, top-down directions.
Reverse indexes subtly encourage people to categorise as they go. They are constructed by answering the question "What categories does this page belong to?" rather than "What pages belong to this category?" Thus they are content-focused, not category-focused.
Unlike ForwardIndexes like a TableOfContents, reverse indexes are normally limited to one BackLink level since they quickly deform from a simple tree into a more generic graph. However, see ReverseIndexTree for a partial, practical solution.
A BidirectionalIndex is both a forward and a reverse index.
A reverse index, unlike a forward index, prevents one LinkingWithoutIndexing.
A ReverseIndex on a wiki with a LinkPattern is often implemented as a search for a page that contains a query word, though they can also be done using a LinkDatabase. A LinkDatabase is the more generic solution for CollaborativeHypermedia.
I imagine some of those drawbacks could be fixed by TechnologySolutions. The index generator would need to extract more info from the page it was indexing, and people would have to fill that info in. The info could be fairly generic, e.g. a short summary of the page's content (perhaps the first sentence of each page should contain such a summary anyway), or specific to the index.