Q: This won't scale. Won't it be way too slow as the number of users (and thus directory entries) increase?
A: I realize a lot of filesystems are deficient when it comes to directories with a large number of entries. Fortunately, FreeBSD has UFS with DIRHASH and Linux has Reiserfs which don't suffer from these shortcomings. As for performance, this scheme still probably isn't going to beat a Berkeley DB file (or CDB file) or possibly even reading sequentially from a flat /etc/passwd file, but the way I see it is, the increase in flexibility more than makes up for the (possibly negligible) performance loss.
Q: How about a directory hashing scheme so it's not all under one big directory?
A: A hashing scheme (i.e. /etc/users/d/r/drench/) would break the very clean and simple API of disk I/O on files under /etc/users/USERNAME/, unless we can all agree on a consistent "depth" (highly unlikely). As I said above, if performance on large directories is an issue, that's a filesystem problem, and it's one that's been largely solved.
Q: Why not make SHELL a symlink to the shell itself or DIR a symlink to the user's home directory?
A: While it would be nice to be able to cd /etc/users/drench/DIR to get to my home directory or execute /etc/users/drench/SHELL directly, I think it's even more important that shell scripts be able to do things like HOME=`cat /etc/users/drench/DIR`. It also then ceases to be an envdir (i.e. I don't want the contents of the variable SHELL to be the binary contents of the executable). I also like consistency: you can change any field with echo 'value' > FIELDNAME in the current scheme. I don't want to go down the path where some need to be symlinks, and some need to be plain files. Plus, this is Unix. If you want to execute your shell, type `cat /etc/users/mylogin/SHELL`.
Q: Wouldn't it be more appropriate to use "HOME" for the user's home directory instead of "DIR"?
A: I considered using different names for the files, but I decided that being a drop-in replacement, it would be appropriate to not deviate from the names as they are defined in struct passwd. So the filenames are identical to the structure, except that I uppercased them. You're always free to symlink HOME to DIR if you like.
Q: Why /etc/users? Why not register a name under slashpackage?
A: At first I thought about putting it under /config/users or /users, but I settled on /etc/users because the fact is there are many reactionaries in the Unix community who would dismiss the concept out of hand if I had done that. Witness the hostility toward the work of D.J. Bernstein. Still, I'm sure a lot of people are going to dismiss userdir out of hand just because it's still too radically different from /etc/passwd. As for slashpackage, I'll consider it, but ultimately I want to see userdir as an integral part of every Unix system, not an optional package. If I'm misunderstanding the concept of slashpackage, please correct me.
Q: Why not just use /home? It's already there and already includes user metadata in the form of dotfiles and the like.
A: That's an interesting idea. I need to ponder that, since I do have a few concerns about it. For one, most system administrators let users own their own home directories, and there are certain fields (UID in particular) that only the system administrator should be able to modify (simple root exploit that would work under the current implementation under /home: rm ~/UID && echo 0 > ~/UID). There are ways to lock this down, certainly, but I'd like to make the transition as painless as possible. This would also break envdir unless we created another subdirectory that contains the Userdir fields, like ~/.userdir/. There's also potential confusion: I have a lot of users whose home directories are not under /home. So for example, /home/pgsql/DIR might contain /usr/local/pgsql. Not really a big deal, and it's something fairly easy to work around with symlinks. If you like, you can try it under /home right now: ln -s /home /etc/users.