It isn't the fact that stuff goes wrong that bugs me, it is the fact that seemingly both the problems and solutions are via "magic." Even people who claim to be very UNIX knowledgable have no idea what is going wrong...
When Apple's stuff works it "just works." When Apple's stuff stops working then you're SOL.
Sounds like rationalizing the non-purchase to me.
Nothing voodoo about how OS X works. Just that nobody bothered to investigate this problem further (and that OS X sandboxing a custom component, and a recent one at that, not some standard UNIX/POSIX functionality, so not everybody is familiar with it). My guess is that the safe-boot thing lets some maintenance scripts run uninhibited by restrictions set in other run levels, which fixes the md issue.
That said, md is just a normal unix process. If you cared enough to find this out, you can see what's going one with fs_usage, you have Dtrace available and other niceties etc.
In any case, nothing unlike the numerous problems people have with the intricacies of selinux.
As for Windows... just restart it, you'll be fine. ;)
Maybe the hardware problems is for the stereotypical consumer isn't interested in Linux if you compare to Windows and Mac OSX. Different story on server-hardware/software though.
I don't find this latest OS X buglet to be difficult to understand, but then, I've been using OS X for ages.
#edit: also, how exactly does one get as familiar with a closed source OS as an open source one?
I'm sure on some level that's true, as you have the option to learn how, say, your WiFi drivers operate to decipher why your signal drops to three bars every 20 minutes.
However, in Windows, I generally know where to find configuration info: In one of three registry hives, which follow a pretty easy to parse tree structure.
In Linux, I'm totally lost finding where to configure different pieces of software. Each distro puts their various configs in different spots. Some in /etc/local/whatever, /etc/whatever/, /usr/share/local/whatever.d/, /opt/whatever/, /etc/opt/whatever.conf/, /usr/local/share/whatever.d/ and so on. Some times there are duplicates, which one is the correct one? How do I know? And on top of this, every config file uses different formats.
If you can get a reproducible case and capture enough useful diagnostic information you can give that to Apple to try to get a fix in some future version of OS X. Have a look at /usr/bin/sysdiagnose and /usr/sbin/spindump among other tools. I'm sure there are more diagnostic tools internal to Apple, which would require that you have a case that is reproducible from a new OS X install rather than from a system with files copied over. If you can identify the one file from ~/Library or wherever that triggers it, then you can pass that along as the repro case.
In general people (like me) just don't have the time to hunt down every crash, hang, etc. we find when using a computer. So I can understand if one doesn't bother with capturing diagnostics and repro cases or with downloading Darwin or Android source to debug a crash. I can also understand where huge frustrated discussions like this one come from. But deep down there is an answer, and it likely is not from some huge corporate failing on Apple's part.
Work for Apple.
Well, since you used "usually" and "some level", the same exact thing holds for OS X.
If THIS particular one doesn't make sense, it's because nobody bothered explaining the mechanism yet -- which should be trivial if investigated.
Isn't it obvious that "safe mode" boot foregoes running some system stuff? That probably lets some script the chance to fix something (bad permissions?) that it couldn't fix when the full system, sandboxing, mdworker etc were running.
It's just a general fact that, given enough time and some trial and error, one can make problems go away even without understanding the root cause. I don't think it varies so much from one OS to another.