Sounds logical. And I had similar thoughts like that many times, including such as "Why not delete config automatically when a software is deinstalled from the system?"What I want...
If you think it through you will find you would only reduce "$HOME pollution" a small bit for the price to complicate the usage much more.
To answer my own question first: Besides config doesn't occupy noteworthy space (almost always a few kB each) by automatically removing user's config you would kill each user's config *cough* - what if a user spent lots of effort into her personal config? (Don't forget: We are on a multiuser system.) What if the user wants to keep the config for the case the software will be installed later again? (e.g. saved games may be put into this suggestion, too) Or the user wants to copy the config to another system?
It's better for to give each user the responsibility to delete her individual config if not needed anymore, than complicate things even more, like producing the urge for workarounds for the danger of automatic deletion.
As I sketched in post #17 automatic placed configs are only one cause for what we call here "pollution". And in my eyes this is just a minor case. Since "reduce pollution" can also be named as "keep your /home/ clean and in order" is primarily the user's own personal task: to create structure, move files, remove not needed things - it is organization, and discipline, and as I also pointed out, a learning process.
Otherwise a user will mess up her /home/ sooner or later anyway - with or without configs.
And I think I also gave in my post some ideas that at least help me to keep overview over my /home/, which for example currently comes to 74 lines for a
ls -la ~
- and I bet others will have way more entries in their home, neither lost overview, nor have the feeling to have messed up their place, drowning in useless garbage, files forgotten to be deleted.I guess we're all roots here, on our, and maybe other systems. But since Unix and unixlike are multiuser systems you also need think of only users, while I'm not talking "no root access" here, but "by far not the knowledge as a root." So in my eyes the idea to ask the users to copy config from default sources somewhere under /usr/ when wanted, was maybe not easier than what we have now.
Bottom line:
You can turn it as you like, you always get things could have been better, even flaws in a system having its roots over fifty years ago, of course. And even known and seen as flaws some things simply cannot be changed if you don't want to get a bunch of other, maybe even bigger problems instead, like compatibility issues with older software, or software from other unix[like] world.
And there also are always things you simply would not get an improvement when you change them, but only change the kind of complication, or move it to another place - so nothing won, really. Or, as we say in german: The choice between pest and cholera.
And sometimes there are just some things coming as an characteristic of the system. You simply have to learn and accept it.
Thinking about it will bring you on many cases to the conclusion (at least in unix[like] {that was a joke on MS Windows}):
The people who made a decision gave it a good thought, and had very good reasons to design things the way they are. In case of FreeBSD comparing it to all other systems I experienced so far in the last fourty years, many of those choices weren't the worst ones.

In many situations when decision are needed only compromises can be made, since sometimes there is not the one and only perfect solution. And, yes, on other systems you may find single things made better as here. But I am convinced with FreeBSD the overall compromise is best - it is at least to me. Others will have other needs and preferences, and I accept that
