Follows up on .

See the discussion starting here:

> And now, by reading the examples with lambdas, i.e. when the operator instantiation and the add operations are distant from one another, I'm wondering if such syntax isn't requiring an excessive cognitive load for casual readers to figure out what kind of operation this add is performing. I'd say the cognitive load would be reduced if the methods were to be more explicitly named and and or.

That means getting back to the situation before you de-duplicated all the interfaces, then :) That might be clearer for long chains of .add(), but I find it strange to use and/or for the very first clause, and that would also feel very redundant, e.g. f.and().and( e1 ).and( e2 ). It would also prevent developers from writing "generic" functions that simply add multiple clauses to a boolean predicate, without knowing whether it's an and or an or; not a big deal, but worth mentioning.

> In addition to making code more self-explanatory, having specific "add" methods would be less error-prone when different predicates are used in different with(...) constructs, as in "Example 228. Easily adding clauses dynamically using with(…) and the lambda syntax".

That wouldn't make things less error-prone for and/and nesting though, e.g. f.and().and( ... ).and( f.nested().and( ... ).and( ... ) ).

> For the forthcoming not predicate (HSEARCH-4645), renaming add to something like andNot may also be more explicit.

To me that's one more reason to not introduce and add syntax for not: make that predicate accept a single inner clause and leave it at that. People can still nest an and predicate if they want to, and we can always try to "flatten" expressions under the hood with some tricks (which we'll probably need for the not() predicate anyway).