Let's try to enumerate the costs and benefits of adding source suffixes. I want to avoid the conversation getting stuck on one side of that equation.

What becomes easier with one or more additional source file extensions?

  * A build tool could look at the source file extension and make a high quality guess about which tools should be used on the file, and what artifacts will be produced by running that tool.
     * For example, a build system could look at a .h file and not run the compiler on it. It could look at a .cpp file and run the compiler on it and expect a .o file output. It could look at a .cppm file and run the compiler on it and expect a .o and .bmi file as outputs.
     * Globbing build systems would like to know which extension(s) to use in the globs that will eventually be fed into compiler invocations
  * A person could look at the source file extension and make a high quality guess as to what kind of thing is in that file. Some people will want to be able to tell whether a file contains a primary module interface, a module partition implementation, or a traditional textual header, all from looking at the extension.
  * A file extension could indicate which files provide module interfaces, making it easier for a scanner to find those things
     * Note that this isn't that big of a deal, because a build-time scanner is probably going to need to scan everything to see who consumes what.
  * Whatever else I'm forgetting. Reflector, fill in this spot

What becomes harder with one or more additional source file extensions? Are there mitigations?

  * Some build systems take the input file name and generate and output file name by replacing the source file extension with the destination file extension. For example, foo.cpp -> foo.o. If we have multiple file extensions that produce a .o, then we will have conflicting output files.
     * Mitigation: Don't perform foo.cpp -> foo.o. Instead perform foo.cpp -> foo.cpp.o. CMake and some other build systems do this.
     * Complication: Some compilers don't let you choose the name for some output files
  * Text editors and IDEs that don't recognize the new extension may incorrectly colorize, auto-complete, and indent code.
     * Mitigation: Most text editors let you customize which extensions map to what language
     * Complication: The editors would benefit from updates to understand the rest of C++20 anyway, including all the new keywords.
  * Dialogs like "Add File..." and "Open..." may not show files with the new extension by default
     * Mitigation: There's usually an option in the dialog to show all files
  * Migrating code from a text header to a module interface requires (or at least strongly encourages) a file rename
     * Complication: If your build system also does extension replacement (instead of appending a new extension), then you may also need to change the file base name.
  * Compilers, and some other multi-language tools make guesses about what language a source file is based off of the extension. These tools need to be taught the new extension.
     * Mitigation: Most of these tools can be told specifically the language of a source file.
  * Whatever else I'm forgetting. Reflector, fill in this spot