It seems to have been specifically designed for developers who enjoy a difficult UX because anything not up to that standard that is childish to them, which in my experience is the same thing Linux tools optimize for. I guess Windows has been very much trying to cater to that sector, so maybe now I can understand its appeal.

The main advantages of config as JSON for me as a developer are:

- Settings become more portable.

- Settings become more shareable.

That said, VS Code started with JSONC-based configs and now presents a UI by default (still editable directly as JSONC for those who prefer). It seems possible JSONC could be used to bootstrap a UI for Windows Terminal too if there's demand.

The fact that it's JSON rather than a nice little window isn't the main issue. That's not great UI, but it's not the biggest pain point of the UX. For comparison, Sublime uses JSON settings too, but it doesn't require a PhD in Sublime Text to figure out what you can actually configure in that file. I seem to recall VSCode had JSON at some point for some things too (though not sure where it is now, I don't see it). It wasn't exactly fantastic, which I assume is why they've provided a better UI for the settings now, but it was usable. They actually described the options available to you right there. And of course they have their own benefits with regards to portability and shareability like you said. Those are all fine. The problem is Windows Terminal on the other hand seems to go out of its way to make your life hard for no reason, in a manner I have never seen another terminal emulator do. For the life of me I don't get what people like about it. It seems terrible on every axis I can measure on.

My reading had been that they plan to build a nice configuration UI on top of the JSON eventually, but the focus right now is on the core functionality (and letting the settings stabilize first).

>> and opening Settings fires up Visual Studio of all things

> Settings opens what ever editor is your default for .json files.

And one can also point out that macOS opens XCode for (even XML-based) .plist files.

It's getting to be a standard convention, now that IDEs are almost "ships with the OS" kind of software, that the OS thinks configuration files should be opened in the IDE, rather than the system GUI text editor (Notepad; TextEdit.) Because, I guess, the system text editors were never really made to edit code, and make no guarantee that they won't break the formatting of code, while IDEs do make that guarantee.