It is possible - with the .js extension. Does that not work for you?

Unlike jpeg/jpg (and I think all other examples in constants.py), this is not just an aesthetic issue. js and mjs are distinct and incompatible variants of javascript (maybe that implies they shouldn't be the same mimetype but that's a battle I have no interest in). mjs files include keywords like import/export that are syntax errors in js files. Similarly a js file loaded as a module will not export any symbols, so is likely unusable. So while it's technically possible to just name them all .js and have things work, that would force us to come up with some other convention for letting us distinguish plain and module javascript.

Is there reason not to add mjs?

I'm aware of the difference between scripts loaded as modules and as classic scripts, yes. However, an HTTP client cannot use the extension to distinguish these cases, and this PR does not expose any other difference to the client. So my question remains: what does this change enable you to do that you couldn't do before - considering that you're changing an HTTP server?

This allows other tooling we're using (e.g. ESLint), or just humans, to distinguish modules from classic scripts. Without this change, the HTTP server will refuse to serve .mjs files with text/javascript, which prevents us from using them in tests.

I can personally guarantee that there are many module script tests that would have their readability significantly improved by this change. (E.g. ones where classic scripts import module scripts.) I only didn't introduce it while writing those tests, because I didn't know how. I'm really happy @fergald took the time to fix this.