I agree with you there. I don't remember which it was, but one of the runtimes managers (was it pyenv, rvm or nvm?) wrote to my .bashrc and .zshrc without asking for permission to do so, instead of just telling me the locations it wants me to include in my $PATH. I don't do path munging in my zshrc, rather, I source a different file that I use to manage this stuff and set up a way to avoid duplicates in $PATH and only adding things to $PATH when they exist so that my shell configuration doesn't do anything dumb when used across multiple computers.
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.
It's not that "terrible" in the first place, all things considering, and breaking people's workflow just to satisfy your preferences is just anti-user and a good way to piss off people.
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.)
If it is that terrible, I guess the good way to do it is not to break stuff to people using bash, but to use another shell, possibly a fork that will be expressly known to not use bash original config files.
That way you can introduce the new guidelines while not breaking stuff to those who want the old bash.
