Yes, if you are writing new software please respect $XDG. But its a bit ridiculous to think that bash should respect some convention developed ~20 years after bash was released.
Heck, git adopted ~/.config/git years ago, and yet just last week I ran across a tool that created and wrote to ~/.gitconfig instead of my ~/.config/git/config. If Bash tried to change then we'd be dealing with the fallout probably forever.
Which is terrible, btw. Configuration using untyped, unchecked files, readable & writeable by almost everything is one of the worst parts of Linux. Especially when it exists in a directory the user should expect to be their exclusive domain.
Well, I'd rather their attempt at writing to my shell config breaks.
This is one of the many reasons why you should, if you haven't yet, manage your dotfiles with version control. Many tools assist in giving you some sugar over the process, I use homeshick which will move files away into a git controlled folder and create symlinks.
$HOME/.ncmpcpp -> $XDG_CONFIG_HOME/ncmpcpp
The correct way to handle this, for any projects forcing the change, is to use a staged deprecation period:
* first, you add support for XDG
* second, wait at least one version to give people time to get used to it
* third, switch the config location search order so it checks XDG before .whatever
* lastly, after an announcement and deprecation period, and at least 2-3 releases, remove support for the .whatever folder.
(To be fair, it's totally possible that my upgrade path with ncmpcpp skipped over some steps and they actually did it correctly. Will have to check when I care enough to dig through commits.)
That way you can introduce the new guidelines while not breaking stuff to those who want the old bash.
First, I don't like tools overwriting my configuration. My dotfiles belong to me and I have things configured the way they are for a reason. Tools should inform me if changes are required to my configuration, and not just go and change it by itself.
Second, it prevents users from making their configuration files read only. This affects users of Home Manager by the way, which deploys configuration files as symlinks to read only files under /nix/store.
Even more egregious are files that write mutable state to configuration files, which makes them unsuitable for version control. Unfortunately, Docker is guilty of this and stores mutable state in config.json.
Finally, as mentioned, it interferes with XDG adoption.
Personally, I'm all for breaking tools that write to user configuration files. They cause too many headaches with no clear benefit.
I would then say emacs supports XDG, but doesn't use it by default, right?
This is fair behaviour IMO, because migrating configs automatically might break user setups.
Refer to section 50.4.4 (How Emacs Finds Your Init File) of the manual for more information.