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