I thought the problem with "mh-e" might be related to
punctuation or token size... oh, well.  If I keep on top of
newly filed bugs, hopefully I'll notice any that are related
to MH-E.  Thanks for looking into it, Stephen.

OK, I've figured out where the problem is, but I can't promise a good fix this 
week.  Roundup simply limits the number of hits presented to 10, and provides no 
way to get more!  I've bumped the number of hits presented to 100, which I think 
is about as many as you'd want to look through.  (I plan to do something more 
thorough later, but that should help a lot.)

This does find issue411 with "save options" as the search terms ... as hit 
41/41.

The mh-e problem is slightly more complex.  I believe that it is indeed being 
split into two search terms, and the term filter insists on at least three-
letter words.  So mh-e loses.  I'm not sure how to deal with this; it may be a 
limitation of the underlying indexer (Xapian).

I've upgraded Xapian (the text indexing tool) and PostgreSQL on the server, 
and reindexed, to no avail.  And 'options' still doesn't work.  I wonder if 
there's an issue with the length of the search term (although 'options' 
should be enough I would think).
There's an issue in the (upstream) Roundup bug database where the Roundup 
maintainer says that search terms are basically split on alphanumeric 
sequences.  That could explain why 'mh-e' doesn't work, if the indexes are 
split that way too: 'mh' and 'e' are probably both too short.
Sorry, no joy yet, but I'll keep working on it.

Seems worse now.  Even searching for "options" does not find
issue 411.

Another search test case: if I search with "all text" set to
any of

    mh-e
    "mh-e"
    mh

I get no hits.  Yet at least one of them should find issue298.

But searching for 'options' does!  
Both in the upper right search box and using the advanced search screen.