Magic filesystems are too clever

Ew. No thanks. I find the /proc/$PID directories utterly crucial for all sorts of things. The problem with needing tools and sysctls to get at things is that they're not shell-compatible: you *must* write a tool to access it, and in extremis you can't do this because there isn't time; but you *can* cd into a directory and use ordinary shell tools. It's also crucial for non-emergency but adhoc stuff, which is a huge proportion of the stuff people actually do (as the non-adhoc stuff can be automated).

And for systems-administration stuff, well, am I the only person who's ever done a grep -R of /proc/sys/? Surely not.

Being shell-transparent is a huge huge huge feature. Don't break it.

Bringing up ps(1) as a counterargument is ridiculous: the reason ps(1) exists is both compatibility with Unix and that it can provide heaps of features that would be really annoying to implement by bashing on /proc yourself. But having /proc made ps(1) a hell of a lot easier to implement than it would have been otherwise (how else would you do it? grovelling through /dev/kmem, like traditional Unix? files in /proc with heaps of magic ioctl()s, like Solaris? Oh, please. We're moving *away* from that sort of opaque nightmare.)

(I'd actually quite like rm -r /proc/$PID to be made equivalent to kill -9, but I haven't implemented that or even tried to.)