Property access works differently depending on whether using "this" or other reference even if they point to the same object

The bug is still around

class Foo {
  def aproperty
  def getAproperty() { this.@aproperty ? this.@aproperty : 'a default value' } 

  def test(){
     def other = this
     assert other.@aproperty == this.@aproperty
     assert other.aproperty == "a default value"
     assert this.aproperty == null // ???
     // thw folowing line fails
     assert other.aproperty == this.aproperty
  }
}

def foo = new Foo()
foo.test()

What's weird about this is that is seems there may be an optimization while accessing properties with 'this' as it yields the filed vlaue right away, but with 'other' it follows the long path.

I'm under the impression that this is actually by design to make things more familiar to a Java programmer; I recall it is described this way in GinA book. IMO, though, it is a design mistake as it makes the language inconsistent.

I believe this issue is related to GROOVY-1569

The issues are not really related, because GROOVY-1569 is about the dynamic scoping once you hit a closure and this here is more about calls from inside a class and from outside a class. Of course the other issue is about this as well, but that is not the sole part there, while it is here. So, what could be doe to make this behave more as you might expect? For example we could check if "other" is the same class as "this" and then use the same access mechanisms... hmm.. no, I think that won't work if I think about subclasses... So what we really would have to do would be to check if "other" is an instance of Foo and then access the field Foo#aproperty directly, instead of going through the getter. Which means this makes this the same problem as with typical equals code, that checks private fields. After this change other.aproperty would return null.

The other way would be to go through the getter all the time, but we decided to not to do this or else poeple will always have to write this.@aproperty when they want to access the field from the current class.

IMO checking whether "other" is an instance of Foo and acting on that will cause very confusing behavior, so that idea can be discarded.

Also, IMO it would be much more consistent to go through the setter all the time and use @property when one really wants to access the instance variable. I realize that this is a major change and would probably break a lot of existing code so it might not be doable.

It could also be that it's just me who finds it confusing that o.property goes via getter, but this.property does not. Well, now that I know it it's not confusing any more, just annoying. And inconsistent - if a language feature has to be described "XXX works such that YYY except when ZZZ it does WTF" it should be seriously reconsidered.
But like I said, it may be too late to change this any more.

This really does seem like a bug.

Is fixing this going to be targeted for 2.0?