aBlock, anotherBlock, yetAnotherBlock ifAllTrue:... "n-ary and"
	aBlock, anotherBlock, yetAnotherBlock ifAllFalse:... "n-ary and"
	aBlock, anotherBlock, yetAnotherBlock ifAnyTrue:... "n-ary or"
	aBlock, anotherBlock, yetAnotherBlock ifAnyFalse:... "n-ary or"
	
I started with infix notation (Fortran 66 and Algol 60).
I learned to like prefix notation (Lisp and Prolog).
I _don't_ like postfix notation.

I'm willing to put up with
	{   e1.
	    ...
	    en
	} do: [:x |
	    ...
	]

if it is laid out so that the "do:" or "collect:" or whatever is
VISIBLY salient.  So
	{   [block1].
	    [block2].
	    ...
	    [blockn]
	} ifAllTrue: [
	    ...
	]
might be tolerable.

The main problem with
	expr1 and: [
	expr2 and: [
	...
	exprn ... ]] ifTrue: [...]
is that the pretty-printer destroys the layout.  That could be fixed
by improving the pretty-printer.

		^BlockContextComposite with: self with: aBlock
	
The real question is the semantics of BlockContextComposite.
In some of the examples, the comma "means" AND, in some OR, in some
a sort of NOT-AND, in some a sort of NOT-OR, and then why not include
sumOfAll, productOfAll, leastOfAll, ...

We already _have_ messages that summarise "composites" in various ways,
and they apply to collections.

	aBlock, anotherBlock, yetAnotherBlock ifAllTrue:... "n-ary and"
	
becomes
    ({  aBlock.
        anotherBlock.
        yetAnotherBlock
     } allSatisfy: [:x| x value]) ifTrue: [
	...
    ]

with corresponding variants for the other three cases.

Myself, I'd be looking for a way to rewrite the code.
What was the real example again?