I've always kind of wondered why rmdir(2) only deletes empty directories. (I suppose it could be simply to keep the recursive directory traversal logic out of the kernel.) One can usually just recursively delete directories so this doesn't matter but I ran across a situation where it does actually matter that rmdir only deletes empty directories that I hadn't considered before.

If directory /containing is writable by user u and directory /containing/private is not writable by user u, then u can delete /containing/private only if /containing/private is empty.

This kind of feels like it's a security/access control choice. Does anyone know if this scenario was an explicit consideration when the rmdir system call was being designed? (The macOS man page suggests that rmdir(2) appeared in 4.2BSD.)

@stevecheckoway I strongly suspect that it’s historical. In particular: if rmdir(2) dates to 4.2bsd, how did one remove directories before that. The answer can be found by looking at the source to, e.g., v7 rmdir at https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/rmdir.c — it simply unlinked the directory. Only root could do that (and yes, rmdir(1) was setuid (and I think insecure against race conditions), but without good locking (and Unix didn't have good locking then) you could end up with a tree mess if non-empty.
@stevecheckoway Even if you can't write /containing/private you can rename it somewhere else. This is fundamental to the directory permissions model.
@dalias I've never thought about needing to move a directory not owned by my user except as root.