No one is forcing you to change your broken buggy 30-year old shell scripts, you can always continue using them.

How about usernames that start with a digit? Am I still allowed to use those?

* https://ma.ttias.be/giving-perspective-systemds-usernames-st...

Now assuming I have a user called 1000 with UID 2000, and a user called 2000 with UID 1000.

Now what do you think is gonna happen if multiple POSIX-compliant tools call each other?

This is clearly broken, and the reason why BSDs don’t actually implement POSIX cleanly, instead allowing all their tools to take unambiguous identifiers on the CLI, with the # prefix to mark a UID, and have all their tools call all their children with this format.

The POSIX standard is clearly suboptimal here, and the set of valid usernames, and the set of valid UIDs should never have been allowed to overlap.

But how large a proportion of machines do you think have mail delivery rely on .forward or .procmailrc in $HOME these days?

In any case, procmail can be executed directly rather than from .forward in most cases, and can be configured to take the rc file to be a file in /etc/procmail-rcs/ as an alternative to $HOME/.procmailrc (at least the version of procmail in Ubuntu; unlike /etc/procmailrc, the files in /etc/procmail-rcs/ will take on the user id of the user the file is named for, like $HOME/.procmailrc).

User crontabs on my system at least (Ubuntu) are in /var/spool/cron/crontabs/[username], not in $HOME anyway. I can't remember the last system I had with user crontabs in $HOME.

People have had systems where relying on accessing the home directory of a logged out user has been undesirable or impossible for a very long time.

I help run a 500 node HPC cluster that leverages procmail. Do I count?

> User crontabs on my system at least (Ubuntu) are in /var/spool/cron/crontabs/[username], not in $HOME anyway.

The crontab(5) may be there, but where is the script that is actually executed? Probably in $HOME/scripts/ or some such.

> People have had systems where relying on accessing the home directory of a logged out user has been undesirable or impossible for a very long time.

I have daily experiences indicating otherwise. I would hazard to guess that many other syadins in academia & research would agree. Even assuming $HOME is in /home breaks a bunch of stuff:

* https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu2004Sna...

You do, but you're a tiny minority, and as noted /etc/procmail-rcs/ provides an alternative to putting them in /home. If that doesn't work for you, all you need is to not configure encrypted home directions and nothing changes.

> The crontab(5) may be there, but where is the script that is actually executed? Probably in $HOME/scripts/ or some such.

So don't configure encrypted home directories, then. Nobody is forcing you to enable it. Or you can provide an alternative location, and let your users protect their data better and still be able to use cron jobs. It does not take any flexibility away from you, but it adds capabilities for those who want them.

> I have daily experiences indicating otherwise. I would hazard to guess that many other syadins in academia & research would agree. Even assuming $HOME is in /home breaks a bunch of stuff:

Your experiences with systems that are fine with accessing $HOME does not mean that there aren't plenty of systems where it has been an issue, hence why plenty of software supports alternatives.

Your point of not assuming $HOME is in /home is irrelevant to this issue. The point is that software have had to deal with a subset of users with setups where a users home directory is not necessarily accessible when the user is not logged in for many years. As such most software has options to avoid relying on a users home directory being present already, which reduces this to a relatively simple choice of whether or not you consider the ability to encrypt home directories to be worth making those changes for.