If I want to understand a programming language feature, I read the language spec, a manual, or, if all fails, the source code of the implementation.
While that's indeed an invalid expectation, the term "delegate" is used technically in Objective-C, for example, in a way that cannot be related to "prototypal inheritance". The "delegates" don't use the resources of the delegating object. Quite often, they provide resources or data to the delegating object.
JS's prototype system doesn't fit this model of "delegate" either 'cos the "delegate" does appear as though it is wearing the delegating object's shirt. The delegate itself (if you still want to call it one) has no identity apart from the delegating object in JS, whereas that isn't the case in ObjC.
> If I want to understand a programming language feature
This is not so much about understanding a language feature. It is about a model of system design being force fitted onto the language constructs. The language feature itself is dead simple and doesn't need to be viewed through the filter of OO to "understand" it.
If I would want to learn about prototype OO, I would check out the founding papers. Stuff like:
http://selflanguage.org/_static/published/parents-shared-par...
Parents are Shared Parts of Objects: Inheritance and Encapsulation in SELF
Using Prototypical Objects to Implement Shared Behavior in Object Oriented Systems
Objective-C taking a specific meaning for that term is nowhere near as ubiquitous as the point I made that "inheritance" has been so well defined across so many class-oriented languages (for decades!) that borrowing the term for [[Prototype]] is a confusing mistake.