I suspect they were never implemented because BSD has a strong rep as
a "hacker OS" - put in features only if you're the inventor, or there's
a *VERY* compelling reason.  I guess, one of the strengths of Unix has
always been that you put in features most people never need.  Show of hands:
How many people *use* the '-k' option of sort(1)?  I've never needed it -
not in >10 years of hacking and scripting.  Not *once*.  I've used it,
twice, to see what it did.

But if you need it, it's a very good thing to have the tool there, waiting
to be used.  I've yet to see any argument against the run-level idea except
"I never use it; either the system is up, or it's single-user, or it's
down".  Personally, I would *love* to have more states; I want to be able
to put the system in multi-user LAN-only mode, so it doesn't choke on
DNS requests outside the local domain when Kibo breaks the Internet.  I
want to have a remote-login-only state where all the gettys are off,
when I'm mucking with the serial driver.  I want to be able to *bring
services down*, not kill them arbitrarily.  What if a daemon or program
wants to save non-trivial state information before exiting?  A way
to safely bring it down is worth having, and worth making automated.

I shouldn't have to know which processes are part of nfs to shut it
down, any more than I should need to remember whether it's '-n 4' or just
'-4' to bring up four nfsiods.  Sure, I *do* remember - but I shouldn't
have to type it.  And if there's some tricky magic to bringing something
up, I shouldn't need to type it all the time.

The run level and start/stop script thing is a major piece of the modularity
a live system sometimes needs.  I would easily use 10+ runlevels if I had
them.  Not because I'd use any of them all that often, but because
'init 8' is a lot shorter than 'skill -9 nfsiod mountd nfsd telnetd inetd...'

-s