I think this is a combination of a bug interacting with two different things. One is the extension change checker, and the other is the system that adds extensions invisibly in order that the OS can still pretend 23 years later that extensions don't matter. Because while you're right about the fact that extensions shouldn't matter, you're wrong about the fact that they do. Because unlike classic mac os, we don't have file types encoded in the metadata of the file anymore. The only way for an application to specify the types of files it can or can't handle is the extension. And likewise for telling the OS which applications should open a given file type by default. The extension does matter, because it's important metadata the OS and applications use to determine how to handle the file. macOS tries to hide this importance by default and won't show extensions if you don't want it to. But in order for that to work and for files to still be the right type so other apps can know what to do with them, the OS save dialog MUST put a proper extension on the file, even if you don't display it. But now because that's something that can (and will) be changed in the save dialog, it also has to check if you're applying a new extension to a file that already has an extension. Because it needs to confirm if you meant to change the extension or just (as you point out is possible) add another dot separation to the file name. So there's probably a bug in the part that's supposed to be checking for whether it needs to add the extension. Some default case path got broken, and it's taking the case where you save, but include an extension as being saved without an extension because it didn't recognize the extension from its list of "proper" extensions.