Also the proposed "solution", if it becomes implemented by default, would create a severe security issue: if the "\" syntax is used to uinconditionally give access to the parent environment, it will become a way to bypass the sandboxing protection offered by the write accessor defined in the local environment. A user script could then be allowed to read or write protected values that are part of the parent environment chain.
I consider this proposed extension really unsafe, not acceptable in lot of cases. Notably when local scripts are written by external users of a shared service, because users could write scripts that could inspect and modify the caller environment and then inspect the state of all other concurrent scripts on the service, or could easily access to protected passwords (hidden by the sandboxing local environment, or could have access to restricted functions (e.g. using network services in the parent environment to send spam mails, even though these services were isolated and not linked into the local environment which normally offers no way to access other services).
Once again the correct solution for local Lua scripts that want to make sure they are properly isolated and don't affect the behavior other scripts, is to start the script with a simple "require('no global')" which will set the simple accessor into the local environemnt to block the chain of lookups. Then scripts can define their own "global" environment, and create subenvironement where needed for subfunctions in the same script (each function that needs it can also start by the same "require()" statement).
We don't need the "\" tricky syntax at all.
