Change:
assert.strictEqual(suggested, 'plumbus'); registration.dispose(); }); <ins> test('Filename Suggestion - Preserve filename if it matches', () => { const registration = accessor.languageService.registerLanguage({ id: 'plumbus2', filenames: ['plumbus', 'shleem', 'gazorpazorp'] }); const suggested = accessor.textFileService.suggestFilename('plumbus2', 'gazorpazorp'); assert.strictEqual(suggested, 'gazorpazorp'); registration.dispose(); }); test('Filename Suggestion - Rewrites filename according to language', () => { const registration = accessor.languageService.registerLanguage({ id: 'plumbus2', filenames: ['plumbus', 'shleem', 'gazorpazorp'] }); const suggested = accessor.textFileService.suggestFilename('plumbus2', 'foobar'); assert.strictEqual(suggested, 'plumbus'); registration.dispose(); }); </ins> });

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.67.2 OS Version: Windows 10 TL/DR: When saving untitled documents that have name with extension, the proposed file name is not the same and can be completely different: -(I do not have a file with that name ANYWHERE on my PC. I have somewhere though) -Steps to Reproduce: Issue 1: extension command that executes the extension and activate the command to get a new untitled file tab to save the file. The proposed filename is despite the original Untitled file name already ending with which is a valid extension for YAML files Issue 2: extension command that executes the extension and activate the command to get a new untitled file tab to save the file. The proposed filename is , which is unexpected and very surprising. I do not have a file with that name anywhere on my PC. I have somewhere though. Note that the VSCode- extension is here despite VSCode detecting the file format as YAML based on contents. I expect that when saving the file VSCode proposes my given filename and extension to the user. I expect that when saving the file VSCode does not propose completely unrelated file names like .
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.67.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!

Here is how to open an untitled file with associated file path: As for being able to suggest an extension, here is the related issue:
There are certain cases where the proposed solution might not work. The solution requires an absolute file path, but it's not always available. For example, with VSCode Web the workspace might not contain any directories.
I've tested your suggestion and it does not seem to work. The following code still proposes the file name with double extension: does not work either. This bug really breaks the CustomEditor extensions. The saved file is no longer associated with the custom editor due to the mangled name/extension. More so, the Custom editor immediately closes upon saving the file. So the flow becomes: /New File.../ Pipeline on building a pipeline in the custom editor. -VScode prompts for file name suggesting . The user clicks OK immediately closes the custom editor and reopens the file using the text editor (since the file name no longer matches the extension)
Moving to custom editors team for this case.
I think part of this issue is triggered by language detection. I have a hypothesis that the extra is /triggered by the YAML language detector. When the file contains binary data the issue does not seem to be triggered. (I've tested on the modified PawDraw extension modified to propose the file name)
I've just verified the hypothesis. I've modified the CatScratch editor to use the extension and "New Cat Scratch Document" command based on PawDraw. The issue started betting triggered (proposed file name). So the issue is triggered when the document contains valid YAML data (with includes empty file), but does not trigger when the document contains invalid YAML (e.g. binary data).
This also might be related to the "Duplicate editor tab" bug I've previously opened: I've recorded the video that shows both bugs: https://user- See how with first click on "Scratch" another tab opens (with text editor). When saving the custom editor tab, the tab closes (due to the bug we're currently discussing: ).
Repro branch:
me because Ark-kun mentioned language detection... and I own the ML language detection but this has nothing to do with that from what I can tell... it also is easily reproducible without custom editors as the original issue describes.

I this to an barebones extension: With the behavior I get when I save the file is: ! Now if I change it to I get: ! I have no idea what is suppose to be. Trying a different file type (which is a language we ship a grammar for) I notice that this does in fact work as expected: ! So with this said, my suspicion is that something is up with YAML... I noticed I had the Python extension installed so I disabled it and well well well: ! So one that needs to go to the Python extension: "don't clobber the YAML file association". Looks like there are several instances of that in the extension: As for why becomes I'm not totally sure... but a discovery I made was with this list: in the built-in YAML extension (which just provides syntax highlighting). is at the top of the list. If I move to the top of this list, suddenly, this works: ! So two is "all possible extensions should be taken into consideration". I think you own this? What do you think?
nice analysis The issue here is that our logic for figuring out a file name for untitled files is pretty weak: We basically just append the first extension for the language, but we can be smarter: preserve extension when it matches (same for languages that only have file names) actually replace the extension when it does not match so that we do not have 2 extensions piling up I think this fix addresses both issues but would be good to verify then. PR:
so then after this change, what the Python extension is doing is correct to associate YAML with a new file extension?
Yes I do not think that is an issue.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!