I know it's configurable; that's why I included the phrase "by default." The linked issue does not address this.

And I'm not sure, maybe you just didn't read the rest of my comment, but in it I explain that when XDG people get what they want, it becomes literally impossible to configure the software to revert to the previous norm. In other words, when XDG people get what they want, nobody else can.

I'm not sure I'm following you. What state are we considering to be "what XDG wants"? If it's just adding XDG as an option for where config is, then that's fine. If it's replacing custom config location with XDG only, then I would certainly agree that they are unduly influencing things.

It depends on how XDG dirs are handled by the software. If we're forced to use the env vars then it's not really optional anymore. But if the program can default to another location without those env vars set (trivial with an ldpreload script or something), then it supports both.

Vim can be configured to use XDG dirs, if you really want to. Does Neovim limit users to only XDG for its config? I can't think of many pieces of software that outright force XDG. Maybe GNOME stuff?

Every software that follows XDG-basedir stores config in ~/.config if the env var isn't set.

Imagine you have program "foo" which has config, cache, and so on. What XDG-basedir env vars can you set to make it use ~/.foo for all of that? If you try, then because software following XDG-basedir probably doesn't anticipate that XDG_CONFIG_HOME and XDG_CACHE_HOME might have the same value (and because your time is more valuable than auditing the code to find out whether they did anticipate this), you are left with .foo/config, .foo/cache, and .foo/local.

You have created a new "home", and, more importantly, you disallow "foo" from ever spawning a separate program that also uses the same XDG vars. Spawning programs is rather a central Unix principle if you have many tools that each do one thing well.