This doesn't need to be perfect; the backlink search via the page title is always a good last resort.
To the extent that the ForwardIndex is just a way to get oriented, on a wiki a forward index on a category page could be automatically generated by the software, providing the orientation benefit without the maintenance. But a list of all pages in a category is usually pretty overwhelming and hence serves only as an index, not as a point of orientation. However, forward indices can provide additional value if a human picks only a small subset of important pages in the category, summarizes them, and relates them to each other. In this case, each list is more like a TableOfContents for the category rather than an index.
This is why I think category pages should not have forward links to all pages in the category, but rather should be a short "recommended starting points for this category" list. If you want to just have a comprehensive index, instead add a software feature to include the BackLinks on the page explicitly (PhpWiki has a directive to do this, for example). I don't really think this is needed, since we have BackLinks already. The only thing that is needed is the short list of recommended starting points per category.
It works very well on the Emacs Wiki.  I have yet to find an "overwhelming" category page. If the category page is overwhelming, then maybe you need to introduce more categories -- after all, if the category page is overwhelming, the search for backlinks will be even more overwhelming (no summaries, no grouping, no recommendations). And if the backlink search is not usable, then there's no point in having categories in the first place.
Baaah Humbug! I want WikiFeatures:BuiltInCategories?! I want categorization built right into the engine!
This is an instance where I want the engine to take some of the structure work over for me.
Blah. Mysticism won't help you argue your case! Let us move all discussion to this page, though. And answer this: What exact benefits will there be to categories built right into the engine? Can you describe it on a NarrativeLevel (provide a UseCase)? Let me argue my case: If don't like adding information to two pages (child and parent, implementing the bidirectional link as two explicit forward links), then you must be wanting to add the information on only one page. Therefore, you must be wanting something like RdfForWikis. Whether RDF makes it easier to structure the site is still open to debate. I claim that organizing the pages in a category is more difficult if all you can do is edit the pages themselves. You will enter a "edit child, reload parent" debug cycle until you get it right. That's not good. I'd rather edit one parent page, putting the child pages into relation to each other. -- AlexSchroeder
Whereas for the most part, the information that I'd put in the summary on the TableOfContents-like ForwardIndex is just the same one-sentence summary that I'd put on the category page itself. Maintaining it in both places is just an exercise in copy-and-paste. If I had an RdfForWiki system, I'd just write that sentence once, on the page itself, in an RDF field. After doing this 2 or three times, I would trust that the information would appear correctly on the ForwardIndex page, and would not longer feel the need to "reload parent" to check.
So, for me, it is either write the stuff once, or write it once and copy-and-paste.
Hm, does that mean we want something like RDF for wiki pages, where we can provide enough meta information such that a category page can be built automatically? As I said, I'm not too motivated, since it seems to work fine as it is on the EmacsWiki. -- AlexSchroeder