Good questions. You have to realize that this is the order that things get started and not the order that things happen. Most of these steps involve init (pid 1) spawning a sub-process which does the real work. Init generally doesn't wait for the child to finish, just turns it loose to do its own thing, and then chugs onward.
Per TeddyBear, and to misquote Obi-Wan, UTSL. (Use the Source, Luke) ;-)
The timings I posted are the actual times (uptime) when the event happens. I measured these by sprinkling scripts like this all over:
logger "IDENTIFY: [$0] [$1]" uptime: $(cut -f1 -d" " /proc/uptime)
Frankly, a lot of this was surprising to me. OTOH, I made a bet with TB a long time ago about startup timing, and he was right and I was wrong, so WDIK?
W/R/T 3 & 4, they essentially happen one right after the other. But it doesn't make much difference. Syslogd/klogd takes its own sweet time reading its configuration and coming up. And when syslogd does finally come up, it is flooded with the pending approx 145 kernal messages that klogd shoves down its throat.
So, by reordering you could AT BEST get any syslog messages that result from jffs getting mounted.
But, by doing jffs first we have the opportunity to have an autorun script on /jffs do something like…wait for it…creating /etc/syslogd.cfg before syslogd even starts for the first time. Probably not very valuable, but there it is. Heads you don't lose, tails you win.
W/R/T 7 & 10, probably doesn't matter. These are the hardcoded users like root, nas, and nobody. They aren't needed at any particular time (AFAIK) during startup, until later on, so there's no advantage in doing 10 earlier.
Yes, the scripts are run (actually, "invoked") in the order specified, so the nvram (GUI) scripts come first—in each category. Yup, the user scripts are and must be standard Linux scripts or executables. Just as if they got executed from the command line.
Timeouts? It becomes clear when you stop and think about it. Do we want the whole router startup to hang just because some script is taking minutes? No. Do we want to give a script the opportunity to change some config parameter (or something like that) so this new setting is in-place before the next step in the startup? Yes.
The timeout stuff was in the original Broadcom code, and IMHO is pretty clever. What it does is tell the script "You just go ahead and do whatever you need to do. Take your time, I'll just wait until you are done. But you'd better be quick, 'cause I'm not going to wait for more that X seconds."
The timeouts can actually be a PITA sometimes, though. In part of the script I'm developing for tailoring the logfile location & name, I want to wait until the time gets updated. Otherwise the first logfile will get the date of Dec 31, 1969. But it takes upwards of 30+ seconds for the first time update to happen. So I know that it'll exceed the 3 second wait time. So I don't want the parent to wait at all, because any time he waits is just totally wasted. But he'll wait until my process exits or until the entire timeout is consumed. So I had to make that script recursively spawn a child process and then exit, so that the parent will stop waiting. The child is the one that does all the actual work. Kinda tricky though, because if you slip up then you get an infinite recursion.
That's why one of my latest fixes is to *not* wait for the script if the script's filename has an '&' in it, reminiscent of the shell method of spawning a background job. Regardless of the standard timeout for that particular category of script.
I think the doc needs to clarify that "start XYZ" doesn't mean that we wait until XYZ is all done; it just means that XYZ is kicked awake and let loose to do whatever it needs to do.