Rationale for dropping ModuleImport syntax?

[Forbes Lindesay]

If we don't have a really clean and simple upgrade path for all existing users of module systems, I can't see ES6 modules gaining widespread adoption.  If nobody objects to that core premise, we must make it easy for users and producers of modules like underscore, as well as producers and consumers of modules like mkdirp, to upgrade.

Current mkdirp style module:

```js
module.exports = function mkdirp(path) {
  // code here
}
```

Current consumer of an mkdirp style module:

```js
var mkdirp = require('mkdirp');

// code here
```

This is easy to upgrade with default exports as it becomes:

```js
export default function mkdirp(path) {
  // code here
}
```

and

```js
import mkdirp from 'mkdirp';
```

Note that it's critically important that I can call my mkdirp function whatever I like.  e.g.

```js
// The hyperquest module is just one implementation of the "request" function.
// It is important that I don't have to care what hyperquest calls its function internally.
import request from 'hyperquest';
```

For underscore we currently have:

```js
exports.map = function (array, fn) {
  // code here
};
exports.filter= function (array, fn) {
  // code here
};
// many more functions here
```

and

```js
var _ = require('underscore');
// lots of code here
```

It would be nice for consumers who just want the map function to be able to indicate that, as it will allow minifiers to more easily remove unused code, but we need to focus on making sure that the upgrade path is easy for existing people, or they simply won't upgrade.  As such I would like to see the producer look like:

```js
export function map(array, fn) {
  // code here
};
export function filter(array, fn) {
  // code here
};
// many more functions here
```

and then the consumer should ideally look like:

```js
import _ from 'underscore';
```

I would then propose that we allow modules to have either a default export, or named exports, but not both.  This way users of existing module systems just have to learn the `import _ from 'underscore';` syntax to get started, and can graduate to importing just the functions they need later.  We could have `import 'underscore' as _;`, but that doesn't match the import syntax for a module with a default export, which I think creates unnecessary confusion.