I'll chime in as I love philosophical questions.
Ultimately the best solution is sth. integrated with the database (I don't like the idea of setting up and maintaining yet another program). From the out-of-database solutions I found SWISH++ to be not perfect but good enough to make it work (and competition is not any better). PJ Lucas (SWISH++'s author) is a reasonable fellow, he incorporated my patches for daemon search mode and that's why I went with it (I believe swish-e has to either be exec'ed or TCL language bindings would have to be developed).
At the time I was looking at swish-e (a year ago) developement seemed very slow and I believe they didn't make a new version since.
I was not thrilled with SWISH++'s use of C++ but it has an amazingly compact index (around 10% of originals while it's not uncommon for this to be >50%) and I was even entertaining an idea of writing C code that would search from the index (==reimplementing). Not a rocket science but ultimately upgrading libc and gcc seemed like less work.
Anyway, in the context of OpenACS what I consider to be a challenge is designing a good integration of search with the acs framework which means a clean interface that could be implemented with different search engines and provide (and document) one good implamantation with an arbitrarily chosen engine. My view is that as long as it does the job adequatly, search engine doesn't matter. Unfortunately at the time I was looking at this I attacked the problem from the wrong side (the tool) and lost impetus before attacking the real issue.
