> This is still a dynamic error (a reference error, like Rick said),
> which I'm not really happy about.  The only alternative I've thought
> of is changing such properties to non-configurable at compilation time
> of the module that references them.  But that's a weirdly non-local
> effect, and is probably worse than the disease.

There is the alternative that you error on all non explicitly imported
variables.
If this system were being designed in a green field environment I'd
imagine that's how it would be built.

I realize that means people would have to

import {console} from "std/console";

for logging, but that's hardly such a crippling issue once proper IDE
support exists for ES6 modules.

I'd imagine auto complete will insert that at the top of your .js file
if you are using it inside a module.

Why allow global scope to leak into a new module?

> This is still a dynamic error (a reference error, like Rick said),
> which I'm not really happy about.  The only alternative I've thought
> of is changing such properties to non-configurable at compilation time
> of the module that references them.  But that's a weirdly non-local
> effect, and is probably worse than the disease.

There is the alternative that you error on all non explicitly imported
variables.
If this system were being designed in a green field environment I'd
imagine that's how it would be built.

I realize that means people would have to

```js
import {console} from "std/console";
```

for logging, but that's hardly such a crippling issue once proper IDE
support exists for ES6 modules.

I'd imagine auto complete will insert that at the top of your .js file
if you are using it inside a module.

Why allow global scope to leak into a new module?