Well, there's a lot of options there, and I'm not sure I want to choose
one.  Instead, I'll offer my opinion on what I think is `best' :-)

1. rc scripts.  I like the idea of dependencies much better than that of
   choosing a number.  I want the rc scripts there so that I can arbitrarily
   start or stop sub-systems within NetBSD, be they NFS, named, etc, without
   having to manually work through the steps by interrogating /etc/rc.  The
   advantage of dependencies over numbering is that no matter what numbering
   system you choose, you will eventually become "crowded" in some section
   as "before this and after that" scenarios get slotted in.

2. rcX.d directory names.  I have only one problem with having only
   /etc/init.d for holding scripts and that is there's no obvious way to
   have scripts get executed for booting into single user mode as distinct
   from being a part of the bootup into multiuser mode.  Other than that,
   unless we have run levels, rcX.d is bad, IMHO.  I'm not a fan of run
   levels except for single & multiuser modes so maybe what I'm saying
   is that the directory names should be "/etc/rc.single" and
   "/etc/rc.multi" (duck).  At least that makes it more clean, as distinct
   from having only /etc/init.d, what scripts need to be exercised when
   shutting down from multiuser mode to single user mode.

3. As for vendor scripts and numbering, etc, vendors are in the shit anyway
   because the standard script used on Solaris (or linux) will not work on
   NetBSD with the current implementation due to the "run_rc_command" method
   being offered.  So if they need to do a custom script for us, they might
   as well do it right and add the right dependencies.  I think you've
   missed that difference when comparing what's being offered with what is
   in place today.  That is unless you'd scrap the "run_rc_command" code
   if "dumpstart" was no longer needed, etc.

4. Offering multiple methods.  This sucks more ass than having one or the
   other "bad method".  There can be only one.  As is often said around
   here, "do it once, do it right".  In the past we've not had any scope
   for choice so why the future must offer it seems unclear, except to pacify
   those who are likely to be vocal in opposition, jumping up and down until
   they're red and blue all over.  Whilst offering people choice seems good
   now, sometime down the track when we're supporting this, we need to bear
   in mind that we're supporting a multitude of rc script startups rather
   than just one method.  I can't see that making life easier for us to
   support it at various levels.

5. The old /etc/rc style.  Dispense with it.  It's nothing but a speed hack,
   really, and support for it seems to agree with that sentiment well.  There
   have been a lot of changes, in the recent past, which have resulted in
   slowing of things here and there (e.g. using -O2 rather than -O).  I've
   heard people complain about it being slower but nobody seems that fussed
   that they've actually gone back to using -O) and they've been pretty much
   accepted as a part of NetBSD.

6. I really don't like the current design for rc scripts with "start_cmd=",
   etc.  It unecessarily restricts an independant script on the contents of
   that script.  Each script should be run, not define variables which get
   executed.

Darren