On reflection, it's couchdb-lucene's bug, not couchdb's. Let me explain.
CouchDB-Lucene (to give it its grown-up name) compares the update_seq from a GET /dbname to the sequences a background process is indexing through. It then unblocks searcher threads as that process reaches or exceeds the required update_seq. This is, in fact, just silly.
Instead, a search query should cause a GET /dbname/_changes?since=<latest index checkpoint>. It should block until it consumes the entire response, passing the updates to the indexing process. It can then return a non-stale search result. In the case that the index is fresh, the _changes response contains no rows, and serves only to confirm that the index is fresh. If, as planned, CouchDB-Lucene also runs a _changes?feed=continuous to keep indexes fresh in the background then indexes will simply be fresher than they would be in the CouchDB case.
I repeat, CouchDB-Lucene's mistake is to only use the feed=continuous variety of the changes feed. This prevents it from knowing when its own index is fresh.
I will make this change next week and I suggest that this ticket be closed with no further action taken.