>>>>Why redefine private scope to local ?
>>>Visual FreePro defines a _caller object which is able to access data in functions on up the
>>>caller stack. Private variables are local variables in function, but they are not visible through the
>>>_caller object. This allows code executing at a given point to isolate its data from external reference.
>>
>>Maybe a new keyword like "Hidden", which is known from properties is better than redefining private
>>in memvars. Any ported stuff will throw errors in the compiler, not hard to trace behaviour differences
>>in the runtime if one instance is overlooked.
>
>
>Visual FreePro adds a new command ON COMPATIBILITY DO compatibilityHandler which operates like ON ERROR in that any time the runtime execution engine encounters source code which is no longer supported the same way, it calls ON COMPATIBILITY. The ON COMPATIBILITY parameters include an explanation of the cause, along with the proposed workaround.

Won't take the time to think through all the edge cases, but am pretty sure in such a central area as scoping variables you put unnecessary stress on future users and your own testing efforts. Or to say it in the Zen of Python: explicit is better than implicit - here for signifying voluntary/conscious use of new form of "private" - which is a big deal IAC as private scope is the default for undefined scopes, so seen from that angle you have set a not too easy entry barrier considering that no official vfp lint is existing and usage of tools flagging undeclared memvars is sporadic to say it nicely - including me, as most of my stuff was NOT developed with budget set aside in advance for porting.

Ask yourself if you are creating a new language or building a slightly better xbase and what the chances are for how many people to try out your stuff at which time in the future for "real" usage.