See also discussion in #1930

I'd argue not to replace the existing read_raw_* functions with a generic read_raw function. In fact, read_raw should just be a wrapper to make it easier for users to load common data formats.

@christianbrodbeck read_raw only needs one argument (the file name), I'm passing everything else to the corresponding read_raw_* functions. So this shouldn't be an issue.

@teonbrooks already implemented something similar in our mne-bids repo.

I think that there may be some value in exploring a generic read_raw function, e.g. support for bids export as @jasmainak mentioned above, but I do think we should work out standardizing the standards across the different file types instead of the catchall **kwargs.
the problem with the kwargs is that you often need to reference the format specifics if all the formats aren't listed in the docstring and at that point, you could just use the existing function. I think if we did have it, we would want it to cover of ~80% use case, and then point to specific readers for add'l functionality.

just my 2c

standardizing the standards

The irony! :)

Yes, I agree. If we just pass **kwargs the user has to read the doc of the specific function, so this doesn't really make things easier. I just thought it is kind of silly from a user's perspective to have multiple reader functions if the goal is to read an EEG/MEG raw file - most users won't care about the format, they just want to load the data. So yeah, either we start discussing a complete revamp of the io functions, or we'll just leave it as is for now.

I think I agree with @teonbrooks - if the args of the different readers are 95% the same, so that a generic wrapper would have 95% of the docstring for the specific functions, we could probably have a tiny bit of **kwargs at the end.

We are, after all, doing this with montages already.

I agree, this is probably not such a great idea. The GUI will abstract this away anyway, so there's no need for a (private) helper.