For reasons of either self-delusion or charlatanism, you won't hear it discussed many places besides here.
Here's another one from history: historical Rebol achieves binding by hiding a pointer inside a WORD!, that identifies the specific context OBJECT! that instance points to. So if you write:
>> base: make object! [
x: 10
x-plus-20: does [x + 20]
]
>> derived: make base [x: 30]
>> base/x-plus-20
== 30
>> derived/x-plus-20
== 50
You now have two objects. But the X in does [x + 20] points to BASE's X. How can DERIVED override this to find its X?
Historical Rebol's answer is that the MAKE OBJECT! for DERIVED does a deep copy of all the function bodies in the base object. If it has 20 methods, each with 20 BLOCK!s in it, then each object instance has to copy all these blocks. There are a number of reasons this is unsettling...in terms of semantics as well as efficiency. It's another issue Red doesn't talk about.
Ren-C addresses it with "derived binding"; copies are not needed. Which means this test runs reasonably quickly ...
Most of my "maximum concern" revolves around these topics:
- Modifying While Iterating
- "Virtual Binding" and impact on Declaring Locals Inline
- Object Representation (just in general, including Block Parity)
- Modules and the Genesis of Binding
- Typeset Representation
These are the areas where the answers impact basically every program written, and where I kind of "just don't know, yet". I haven't come up with clever ways to mitigate risk with limited decisions yet.
Glad you can skim them. I think that maybe if you just kind of do as others do and keep tabs now and again, you'll be able to see when development hits a moment that you might be able to use it practically.
Maybe the most useful thing to carry away is just to save yourself some time on Red. I don't really mind people spinning their wheels over there long enough to get enough experience to see the flaws...at which point they might come out of it ready for the answers Ren-C provides (some working today, hopefully more tomorrow).