Further response to your 27Oct:

> That's it.

There is more.  The Delegator mixin exposes its delegate attribute.
Without that, it would not be possible to pass e.g. insert() down the
chain because (in the case of the Text percolator) insert() is found
in each filter and blocks 'transparent' access.

I agree with your two use cases, but repeat that transparent access is
dangerous in that the class in which the attribute is being looked up
changes for each link on the chain.  You could get unexpected results.
IMO you are giving up stability for convenience.  "Explicit is better
than implicit."

> (Caching is just an implementation detail, whose only purpose is to
> facilitate changing a Delegator's delegate.)

Don't believe everything you read.  While that comment in the code is
true, it's not the whole truth.  If 'transparent' access is made to
an attribute further down the chain, that attribute will be actually
cached, i.e. be set as an attribute, in each DelegatorNode.  I imagine
this was done for performance reasons.  The Delegator.__cache is used to
determine which attributes to delete if a delegate is changed.

I'll defer the Percolator comments until later.

> Now, it seems to me that you aren't looking at Delegators and
> Peroclators as transparent proxies at all.

Not so.  That's my 2. in my msg56862 27Oct.  But I see filters as
having two modes of operation.  In the first, they take an action
like insert() and share it explicitly along a chain of authority.
Each link takes specific action, and passes insert() along.  

They also provide transparent access to attributes down the chain, as you 
note.  But once an attribute is found it will not propagate unless
explicitly passed along, and that requires the self.delegate attribute.