I'll mention my little pet idea, which is that I've wanted method members to be accessed via BLANK!-headed TUPLE!s.
Anywhere blanks occur in tuples and paths, they're just an invisible slot in the render:
>> for-each item '//a// [probe item]
_
_
a
_
_
== _
A blank headed tuple is, e.g.:
>> to tuple! [_ something]
== .something
There's also SET-TUPLE! and GET-TUPLE! variants and all of that.
>> to set-tuple! [_ something]
== .something:
So anyway, I've wondered what the evaluator behavior should be for these. And I've thought it would be nice if they would give you the kind of comprehensibility benefit that this->member or self.member offers. So when METHOD invocation patched the environment to the body invocation, it would somehow affect the environment in a way that said "don't put the instance in the main WORD!=>VALUE! mapping, put it in a secondary mapping you get to via .xxx access":
It seems like it's becoming more feasible with this idea that the binding gets sticky and isn't removed after that. Because you could wind up carrying the .xxx over somewhere else where it wouldn't have that secondary mapping available but it didn't matter...because it would still look up so long as it got bound by evaluation in its original location.
It's a feature I'd like, because it can be near-incomprehensible trying to read code and not knowing whether something is an object member. Maintaining Rebmake is particularly miserable due to this.