Most of the $XDG_FOO_DIR dirs are just-in-time created with a `mkdir -p` when something wants to put stuff under them. Given that you're running a program that

Most of the $XDG_FOO_DIR dirs are just-in-time created with a `mkdir -p` when something wants to put stuff under them. Given that you're running a program that manipulates the XDG dirs, that program must already exist somewhere else on your system — so it probably doesn't need to write any binaries. It's already installed! Also, language package ecosystem tooling — the one thing most people touch that could end up installing user-local binaries — is generally just lame and doesn't obey XDG. For just one example, "per-user global" installation of Ruby gems (`gem install --user-install foo`), should properly install the gems under ~/.local/libexec/gem, and then symlink the binstubs of said gem into ~/.local/bin. But it doesn't; it just dumps everything into its own ~/.gem dir and then expects you-the-user to figure out what dir under there to add to your $PATH. Same applies to Rust, Go, Python, and every other language I'm aware of. One thing you can do that will almost-assuredly use ~/.local/bin/, though, is to intentionally point an autotools configure script at ~/.local as its --prefix. `make install` will then dump binaries into ~/.local/bin.