Maybe if new Proxy is created in the lexical scope of class that has private fields, then if the proxy is used in the same lexical scope, the traps for that private "property" could fire (get and set).
Obviously this needs work in considering the edge cases. For example maybe trap code needs to also be defined within the same scope as well? Or maybe trap code doesn't need to be, and this would be a way to purposefully expose private access (to 3rd party trap code defined outside of scope, while the new Proxy still happens in scope).
That's a random thought I had. Are there other plans already?
Proxy is a first class constructor function, not a special form. (A "special form" is syntactic form like a method definition.) Thus, it cannot and must not be sensitive to the scope it is called from.
The one thing in the language that looks like a violation of that principle is the direct eval expression:
eval(expr)
However, it is not. This syntax is recognized specially and treated by the language as a special form. It is an ugly special case that we could not fix in ES3 because too much ES3 code depended on the special-form-like behavior.
const foo = eval;
foo(expr);
means something completely different. It calls the first class eval function with the value of the argument. The callee has no access to the caller's lexical scope.