The problem of the init system is differentiating between bootscripts and the software itself. I actually agree with you that a faulty script should be reimplemented properly, but when an error is found it should at least flag the source of the error, assume the defaults, and upon the last stage of the boot process just before login, it should openly display the error in question, or pause the boot and open the sulogin to repair the faulty trigger(s) at the source, then once finished proceed onward.

However yes, I do segregate bootscripts from the init because many people see this as an argument that init has to do more than it should. Bootscripts are just that in my opinion, bootscripts. Init is a separate entity as I see init as a software package only.

The problem with bootscripts falls on the author, but then again, if people read documentation rather just assuming and assigning bad flags in fstab to devices or expecting uber-magic-utility_X to do all the work for them, situations like this would be fewer and further between. To me there's no excuse for not reading documentation when you choose to use a GNU/Linux based operating system.

Indeed, pausing the boot and displaying the error at hand, so that the admin is able to fix problems, should be the way to do it, but it should do that immediately when the error occurs. The init system can not assume defaults and hope all goes well to the state just before login (not that it would make much sense to start serving processes, like NFS, Samba or httpd, when not all disks are mounted and possibly log storage or the content that has to be served is not available).

One of the many reason why people should read documentation and properly setup a system so that problems are less likely to occur. Problems with an improper parsing of /etc/fstab are less a software issue, and more of a user problem. Had /etc/fstab been properly configured, this wouldn't be an issue.