tmpfiles.d can be used for much more than just temporary files.
For example, it can be used to describe file hierarchies services expect to be present, when StateDirectory/RuntimeDirectory and friends are not enough, and you don't want (or can't) rely on ExecPreStart to set up this structure.
We started using more of tmpfiles.d instead of ExecPreStart in https://github.com/NixOS/nixpkgs/pull/59389, but multiple people got confused on whether it's advisable to use tmpfiles for stateful things.
In fact, it seems to be fine to do that (as long as you don't specify an 'Age' parameter), and https://github.com/systemd/systemd/pull/11122 already did update manpages in that regard, but the name still is very misleading.
Can we get rid of the tmp, and maybe call it just files.d (of course, while still supporting the old paths for backward compatibility)?
Well, I sympathize, but i am not sure this would really be worth the effort. Renaming stuff like that is heavy churn, and is it really worth the effort if besides some bikeshedding about the name there's not much in it?
While tmpfiles evolved past managing temporary stuff, we never really advertised it like this (NEWS, blog post etc.) - so people still have wrong assumptions about it, and I doubt that's easy to change.
I very much agree with @keszybz opinion about naming things in a self-documenting fashion:
Rename to something that should give the user general idea what the setting does without looking at documentation.
We did rename things while promoting them for more externally usage (see https://github.com/systemd/systemd/pull/8623), so I guess if we keep supporting old config paths for backwards compatibility, this can be a sane path forward for tmpfiles, too.
Let's close this. We probably won't change the naming, and after thinking about this a bit more, IMHO people should make more use of StateDirectory, RuntimeDirectory etc., instead of putting things in custom paths and using tmpfiles to create a filesystem structure there.
Most helpful comment
While tmpfiles evolved past managing temporary stuff, we never really advertised it like this (NEWS, blog post etc.) - so people still have wrong assumptions about it, and I doubt that's easy to change.
I very much agree with @keszybz opinion about naming things in a self-documenting fashion:
We did rename things while promoting them for more externally usage (see https://github.com/systemd/systemd/pull/8623), so I guess if we keep supporting old config paths for backwards compatibility, this can be a sane path forward for tmpfiles, too.