Throwing in for my sixpence of opinion, I think this is not a good idea:
I think it's too specific to be useful for clients.

- what reasonable behaviour should a client do when getting a
  130: too many terms matched by masked query term ???
  how should it manipulate a query to take down the count of OR's (if it
indeed is
  implemented like that in your DB ??
  How should this be  presented to the end user ??

-  It is much better to send back a more generic error message -
something like
  a) sorry, I can not do this type of query at all, or
  b) sorry, this query is too complex - for whatever reasons.

   in case of a) you are forbidding queries which can not always be
dealt with - i.e. disabeling a shaky server implementation feature, and
in b) you are telling that a feature, which is normally working, did
fail due to exceptional circumstances.
Then it is up to the human to figure out how a better query can be
formulated.

Marc Cromme, Index Data

Robert Sanderson wrote:

>> No, the problem is that too many terms were generated to be OR'd
>> together.
>> The result set might end up with only one record in it.
>
>
> Do intermediate stages count as result sets? I guess not.
>
> It's also not that the number of records in the intermediate stage is too
> large (as there could be only one record per term).
>
> Okay, I'm convinced.
>
> 130:  Too many terms matched by masked query term ?
>
> With Ralph's example as the note and an unspecified details format?
>
> (As knowing the maximum number of terms that a mask can match is for all
> intents and purposes useless to the client)
>
> Rob
>