Better way to distinguish go.x and go.getProperty("x") in JavaMockInterceptor

This is an issue to track an ability to better handle calling go.x when the generic Java mock implementation is used for an Groovy object in Groovy 3. Currently a working (but ugly and fragile) workaround (aka "hack") is applied, but we hope to have some better way. Related discussion on the Groovy devel mailing list.

A quotation from the original message:

TL;TR. How would be best to distinguish in Groovy 3 foo.x and foo.getProperty("x") in a call (at the level of an interceptor for a mocking system)?

More detailed version.
Working on the Spock adjustment to Groovy 3, I spotted that Groovy 3 started for a property access go.x (go - some GroovyObject instance with a field "x") to call go.getProperty("x") instead of go.getX() directly (as it took place in Groovy 2). This broke tests for mocking with a property call (getX() is stubbed, but go.x is called) and forced me to detect getProperty("x") calls in a mock interceptor - to analyze deeper and check which method (here getter) is being called and if has been stubbed.

However, in addition, it should be possible to just stub direct go.getProperty("x") calls [1]. To do that, currently, I have to analyze a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper process only the other calls (go.x). It seems to work, but it's quite ugly and fragile. I wonder, how to reliably differentiate those two types of calls?

Start at JavaMockInterceptor and reproduce the Groovy 3 distinction between go.x and direct go.getProperty("x") calls. Read the linked Groovy development discussion and verify that the finished approach reliably differentiates both calls without the current stack-trace workaround.