Here is another issue with your proposed (and already spec'ed)
semantics: applying @@unscopable across the inheritance chain is a
breaking change. Consider the following, fairly innocent ES5 code:

  var a = []
  a.values = "Hello"
  with (a) {
    console.log(values)
  }

Under ES5, this happily prints "Hello", under the latest ES6 spec it
would be a ReferenceError.

So it seems to me that it's wrong to apply an @@unscopable black list
to arbitrary objects in the inheritance chain. It should only filter
properties found on its own object.

(Strictly speaking, of course, @@unscopable will be a breaking change
even without that, since somebody might try to monkey-patch
Array.prototype itself with a 'values' property. But monkey patching
has always been brittle, and deserves to break. The above example is
in a different class, since it only concerns a local object.)

/Andreas

Here is another issue with your proposed (and already spec'ed)
semantics: applying @@unscopable across the inheritance chain is a
breaking change. Consider the following, fairly innocent ES5 code:

```js
var a = []
a.values = "Hello"
with (a) {
   console.log(values)
}
```

Under ES5, this happily prints "Hello", under the latest ES6 spec it
would be a ReferenceError.

So it seems to me that it's wrong to apply an @@unscopable black list
to arbitrary objects in the inheritance chain. It should only filter
properties found on its own object.

(Strictly speaking, of course, @@unscopable will be a breaking change
even without that, since somebody might try to monkey-patch
Array.prototype itself with a 'values' property. But monkey patching
has always been brittle, and deserves to break. The above example is
in a different class, since it only concerns a local object.)