Well, you can be written in such a way as to not die unless you want to (try killing a program reading from a disconnected NFS mount..) but I agree it's a straw

Well, you can be written in such a way as to not die unless you want to (try killing a program reading from a disconnected NFS mount..) but I agree it's a strawman argument. In fact, the question is should the shell and init environment overrun the (at least 30 year) unix convention that a user's background processes are not killed when they log out? The reasons given for a 'yes' answer to this question had better be well and truly good, from my perspective. It's not nearly sufficient to say 'some users complain that things are running when they log out'. If you read the original bug report, this all started because some userspace programs aren't very well behaved, and the typical windows or os x behaviour would be to log out, ensuring the OS kills them, then try them again. Generally the advice from unix land would be: 1) Don't use those programs 2) Learn to use ps / top and how to kill a naughty process 3) logging in and out is meaningless when it comes to things running as daemons or in the background. It's pretty shocking to me that someone thinks the best solution is to obviate all that advice. Not that users won't get an experience they expect from other OSes -- they will. But many users will lose a simple experience they rely on, even if they never touch the GUI. That has a bad architecture smell to me, and I think some other solution could be found.