'distance' is not the correct term here.

Well, it's not. As I explained above the kernel breaking, the drivers sucking, the init sucking, the sound server sucking, the application lib sucking, etc etc. The effect is always going to be the same to the end user:

My application is broke, the OS is shit. The user is DOS'd from their application due to a bug.

And the approach for a end user dealing with the issue the issue is always going to be roughly the same:

1. Hack around the problem.
2. Bitch about it.
3. File a bug report
4. Wait a couple weeks, install a update that fixes the problem.
5. Figure out how to roll back your hacks
6. Bitch some more about it.
7. Gradually forget that it ever happened in the first place.

I know there is different levels of pissed off-ness users will get and I know that there are big differences in the difficulty of working around a broken OS component.. but, frankly, I know I'd have a much easier time dealing with a init script then I would with php_mod or a broken Mesa driver.

So how you approach things is a question of goals. Are changes done with reasonable efforts to assure correctness is acceptable, or are then not and the software must be proven elsewhere first?

That is the difference between CentOS/Rehdat and Fedora.