Raising this for discussion for now because I'm curious, but not at all convinced what the right move would be.

We currently have the following options to babel-core:

// Boolean to enable inserting names for AMD/UMD/SystemJS modules, since they are
// normally anonymous because the loader already knows the filename to load it anyway.
"moduleIds",

// Function to modify the AMD/UMD/SystemJS module name once babel-core has generated it.
"getModuleId",

// Provide a default base prefix for AMD/UMD/SystemJS module paths.
"moduleRoot",

// An explicit string name to skip `babel-core`s programmatic generation.
"moduleId",

// Used as the base for module names. Defaults to the "filename" passed to babel.
"filenameRelative"

These are all then exposed via state.file.getModuleName() from babel-core.

We own these module transforms and we want to make the usage as easy as possible, but it also seems strange to me to have these module arguments hardcoded into babel-core. If we do it this way "because it is easiest" that also means that while we get a free pass, noone else could write a plugin that needs arguments like this in an easy, so we avoid dogfooding our own APIs by sidestepping them entirely.

Depending on the usecase, it seems like all but "moduleId" are things that would be pretty static for users, and now that we have .babelrc.js, people can do

module.exports = {
  plugins: [
    ['transform-es2015-modules-systemjs', {
      moduleIds: true,
      moduleRoot: 'myApp',
      getModuleId (name) {
        return name + "suffix";
      },
    }],
  ],
};

They could no longer pass the string ones via babel --module-ids and such, so that's one potential downside. It also means people couldn't just do

{
  presets: ['es2015', {modules: 'systemjs'}],
}

and then use the core Babel arguments to configure the rest separately.

At least some of this is an argument for supporting plugin options in the CLI like #4800

@guybedford I'd be curious for your thoughts as the most go-to person for non-CommonJS module formats.