macOS dotfiles should not go in –/Library/Application Support

$XDG_CONFIG_HOME is clearly meant for data that would otherwise be in a configuration style dotfile. This is the sort of configuration that that users may well want to sync between machines such that a dotfile manager should include them by default. (That said, there may be some data from some of the other XDG directories worth syncing too, but generally a dotfile manager should not include those other folders in full by default.)

Beyond that the spec defines $XDG_DATA_HOME as "base directory relative to which user-specific data files should be stored.". The default path ($HOME/.local/share) might suggest that this should be read-only data, but it actually is read-write.

The description of the $XDG_STATE_HOME makes it quite clear that $XDG_DATA_HOME read-write: "The $XDG_STATE_HOME contains state data that should persist between (application) restarts, but that is not important or portable enough to the user that it should be stored in $XDG_DATA_HOME". This makes it clear that important and portable data should be written to $XDG_DATA_HOME.

And thus we also have $XDG_STATE_HOME. The list of examples that follow the previously quoted sentence make it clear that this is stuff that gets persisted, but if it were omitted from a backup, the user will probably not care too much (i.e. stuff like logs, history, set of open files, undo history, etc.

$CDG_DATA_HOME does also include any read-only reference data, which should be searched for there, and in $XDG_DATA_DIRS (which defaults to "/usr/local/share/:/usr/share/").

It could certainly be argued that read-only reference data and read-write user data should not have been mixed. After all Unix does keep them separate that at the top level `/var` vs `/usr/share`, but the spec authors apparent felt this distinction was not necessary at the user level.

What are CLI tools that work under macOS but not under Darwin? Shortcuts like `code` or `pycharm` that open graphical apps? CLI tools that come bundled with macOS? Yeah these could use the latter.

This is a fair take, and something that I've considered when going down the obsessively organized path.

Does it _ultimately_ matter? No, of course not. A file is a file is a file and if it's located in $HOME or $HOME/.config is immaterial to the OS and, generally, a program. Just so long as it can be read and written to is ultimately what _matters_.

However. Insofar as directories are a construct for humans to mentally parse out and organize data that may be just abstractly written to any number of non-consecutive sectors on a disk, _I'd_ like to at least have a clean mental image of "where" that data is. Apparently, enough people had that same idea and started the excellent XDG spec.

> This isn't silly. At all.

I will grant you that it's pedantic. Both are POSIX-esque systems and to a large degree, talk the same way and expose the underlying infrastructure in a similar manner. However, I think ignoring the platform's preferred organizational methodology is doing a disservice to the end user. If the user wants a vomit of hundreds of . files in their home directory, fine, I'm not your mom. You do you, but I think you should follow the law of least surprise and put things where they're _supposed_ to go, first, then if over-riden, then follow the user.

> but Windows isn't a monolith

It is the very definition of said. There is only one version of Windows, and any marketing faff about different editions are just different coats of paint on the same underlying system. Windows is Windows. You don't have Windows on ARM supporting %HOME%\.datadir\local\system\noreally instead of "AppData". You have AppData and that's it. You can bank on it being the same across all versions of Windows that are still in production, even going back a long way.

WSL1/2 are bolt ons that should behave differently. They're emulating a foreign system, configuration should be stored within, to whatever specification that happens to be.

User data is stored in the user's $HOME, of which none of those locations are, generally, writable to an end-user, and wouldn't be a place to permanently store that data.