@rgrinberg I let you decide of the default, or even whether you want to introduce the feature or not.

While I understand the appeal of using the macOS standard directories and it might be sensible for Dune itself, it seems incorrect in the context of XDG specifically.

Quoting the specification:

$XDG_CACHE_HOME defines the base directory relative to which user-specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

Thus if we return $HOME/Library/Caches on unset $XDG_CACHE_HOME that would violate the specification.

I get @Leonidas-from-XIV 's concern, although I think the use of this library has been to map to the conventions on the operating systems. If not, you could not use the XDG library on Windows.

Maybe we could disambiguate: use a ~strict option if you need strict compliance of XDG? Of course, it would be highly inappropriate to do a strict reading of the spec on Windows, but at least if something really needs full XDG compliance they can get it.

I am really interested in the conventional macOS directories; it is 74 apps+variants in ~/Library/Application Support versus 19 in ~/.config on my machine ... and 3 of those 19 are (wrongly IMHO) influenced by the Xdg library.

"strict" I think is too vague and open to interpretation. I wouldn't mind constructors for Xdg.t that interpret the spec differently. In the end, all that matters for us is how dune interacts with the spec, and not what other users of the xdg library want their programs to do. So if it's useful for them to tweak the standard for their uses, I don't see a problem with it.