The Gand of four wrote Design patterns for the inhertance-based world, because that was what was churning out most business software and had the biggest need for some standard patterns and conventions. And they used (reused?) the word delegation to fit a useful pattern in a non-prototypical language.
And AFACT that's his argument. That all modern OOP languages got it wrong. So they got delegation wrong too. And GOF got it wrong because the wrote it for modern OOP.
Or did I miss anything?
As far as I follow it, the argument is that delegation means, in prototype-based OO (apparently the only context in which either author recognizes its use), that if an object has no method for handling a message that it has received, then it transitively searches through its prototypes for one that can handle it, and if found, the receiving object delegates the message to that prototype's method for handling. When that method handles it, however, it should do so in a way that is aware of the context of the object originally receiving the message, so that, for example, if both the receiving and handling object have a name, the handler should use the receiver's name if it needs a name in handling the message.
If we assume that the methods reference the context they are working with through a variable called 'self', then passing the handling method a 'self' bound to the original message receiver (not necessarily the most recent delegator) will achieve this: any method calls or references the handler needs to make will go through the same delegation process, starting from the original receiver, and in so doing possibly, but not necessarily, ending up at a method from the same object as was picked to handle the original message.
There may be the additional implication that this greatly facilitates composition, which is (it is claimed) preferable to inheritance, but I would think name collisions are a problem.
If you just call a method of another object and then that object perhaps but not necessarily sends some messages back to the original sender, to get further information, that could conceptually be seen as "delegation". But technically that's just normal (bi-directional) message-exchange.
"Delegation" needs to refer to something more technically specific to warrant its existence as a technical concept.
It may not seem novel now, but it was not obvious to everyone at that time that this was a possible design-pattern.
I'm not sure how the author jumps from that quote to:
> When that object delegates to another, then any reference to "self" always refers to the original message recipient. Always.
The high-order bit is that the delegating object can be interrogated for more information or context (and a reference to that object can be forwarded to further delegates), no? Why does that need to be implemented by re-binding whatever keyword or name an object calls itself to a different object?