> 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. Another solution would be to alter conventions, i.e. to use and / or as the name of the lambda parameter (e.g. f.and().with( and -> ... ) ). That would reduce the cognitive load when using with , at least, but obviously not when using the fluent syntax f.and().add(...).add(...). That being said, I'd argue the fluent syntax is more suited to short chains; I’d use.with for longer chains spanning many lines of code. For now, I'll use and / or as the name of the lambda parameter in tests and examples, and I'll open another ticket to re-evaluate the problem before we release 6.2.0.Final.