A few thoughts here (speaking individually only, and not stating a position of any team):
Note for context on this message: I am, in fact, a big fan of the XDG directory layout. I have, in the past, attempted to further this work myself, and discovered some of these details empirically. (Others have done much more and gotten far further.) So, take that into account when considering the explanations below.
I'm going to venture a guess, here, that many folks are not aware of the amount of time that has gone into this issue over the years. It's easy to see a ten year old issue, even with various discussion on it, and treat it roughly as if it idled for a decade, or hasn't been considered important, rather than that:
- It has been a regular topic of discussion.
- People have regularly tried to address it.
- It's harder to fix than you might think.
- It is not higher priority than backwards compatibility.
- Backwards compatibility is more complex than you might think.
- Backwards compatibility includes people who switch back and forth between different versions of cargo.
- Backwards compatibility potentially includes not just people who have cargo configuration, but also people who have a large cache of downloaded files and repositories, and whose bandwidth is not such that they can trivially re-download everything.
- Compatibility needs to take into account that both rustup and cargo have come to share some common directories, which makes it difficult for a version of either to unilaterally move those directories.
- This issue is extremely prone to scope creep.
- For example, as long as someone is working on XDG directory layout support, naturally their design should be expected to fully handle the "correct" directory layouts on Windows and macOS and any other OS Rust and Cargo support, right?
- Not everyone even agrees on what the "correct" directory layout is on every single OS that Rust and Cargo support.
- Multiple people who have attempted to address it have put substantial effort in before bouncing off.
- Nobody involved thinks it is a hair-on-fire priority to address, even those who are enthusiastic about the XDG directory structure or the equivalents on other OSes.
- A huge fraction of the work required here is design and testing, not just showing up with a patch.
- This is not anyone's top priority, nor is it on anyone's roadmap.
- People showing up who come across as "go faster, you're being a nuisance, you're not a good neighbor" have an effect ranging from discouraging to actively taking time away from this and other work.
- It's particularly frustrating when attempts to actually engage with such responses and provide context get treated in a manner that makes people regret making the attempt.
- It's even more frustrating when such responses express indignance at being subject to moderation for not contributing in any way to the situation, despite the fact that they do not contribute in any way to the situation.
- No such messages will at any point have a positive effect, let alone an effect aligned with the goals of the people sending such messages.
- Many, many issues in Cargo have a substantial impact on the ecosystem, both for interoperability with third-party software and for impact on Rust users. It is not, in fact, the case that this one issue and this one issue alone is in the top few issues by importance even if you treat "impact on other people / other people's software" as the top priority and discount everything else.
- Despite all of the above, there is in fact a current effort working on this issue, which has a good shot of succeeding.