And that many choices are not documented in an accessible way. Even default choices. People complaining that desktop Linux is full of bugs and does not work. I think it works pretty well now, but the lack of man pages for anything desktop related is just sad. I'd like to understand how this works so that I'm able to fix it. But I can't easily I have to resort to wild googling, joining others in forums trying to decipher what these daemons are doing. This discourages to fix and understand things. At least for me.

Just some random examples from my Ubuntu Desktop (these are running by default as far as I know)

   $ man dconf-service
   No manual entry for dconf-service

   $ man at-spi-dbus-launcher
   No manual entry for at-spi-dbus-launcher

   $ man console-kit-daemon
   No manual entry for console-kit-daemon
   See 'man 7 undocumented' for help when manual pages are  not available.

ConsoleKit at least is deprecated. For the others, not sure if why you'd expect man files for them. They're just services, not something you'd run manually. If you make your intent clear, file a bug on it.

Because man provides access to the Unix manual? It's a commentary indeed when the man pages on a Macintosh are better.

And there's so little information available/presented to the person who has to make that choice, as to which ones do work, or which ones they should even want to work.

Offline and completely alone I agree, you'd have to try stuff and see what you like. Which is not awful given a decent package management system.

Of course in the modern connected world, you use what your friend showed you, or google, or youtube, or some blog page. screencasts, and tutorials, and faqs. I've never considered the free software community to have a shortage of opinionated highly vocal people.

Someone turned me onto the Awesome window manager, don't remember who or where. Probably 20 years ago I mostly used emacs but the smartest engineer I worked with used vi, so peer pressure struck. I learned GIT from a text blog tutorial quite a few years ago. I watched a screencast on Arduino IDE installation (which was embarrassingly simple and worked perfectly)

Great. Now I have to spend inordinate time mining the proliferation of answers for the correct one. Google is great at showing you wrong/invalid/incomplete answers to questions asked years ago, burying the rare & obscure answers you're looking for.

This instead of it just working, and/or having a definitive central answer site.

You might find some old mailing list that says "oh, you need to grgab version 1.2.3 of package_thing"

But version 1.2.3 of package_thing was obsolete 3 years ago, and the latest version requires you to update your glibc.

I upgrade Linux buying a new system and copying what I want to the new hardware.

Reminds me of hunting for apps the windows way: figure out a need, google for it, find a tool some random person wrote somewhere, try and figure out if the download service they're using is reputable, watch the install process for malware you can see (like drive-by toolbar install tickboxes), et ceter and ra.

Thats a distro problem not a "linux kernel" problem.

Linux doesn't have too many problems with multiple choices. Historically I've seen a couple situations where multiple kernel drivers target the same hardware, but this usually shakes out pretty quickly. Arguably some of the weirder filesystems shipped with the kernel have not quite been enterprise grade. But overall the kernel has high standards.

Coincidentally Debian just released another stable last weekend and the short version is if the maintainer(s) package doesn't play well with others, the package gets yanked (via a release critical bug, which means either you fix it soon or the package gets removed from the release). So either it cooperates with the rest of the system, or its not part of the system anymore.

If there are multiple options, how would QA ensure that these options aren't buggy? I mean the QA in either something like GNOME, a small project, or a distribution.

Just combine the different amount of sound systems (seems to be popular in these comments). Now combine those different systems with different versions of the kernel and e.g. ALSA. Then sometimes things just don't work because of a combination of the sound system and the bug in the kernel (only exposed in one sound system).

Way easier to just standardize on one. E.g. rely on PulseAudio. Then you can still make a standard to have PulseAudio and JACK work together (something that it seems most people here overlooked), but for your project the QA is easier.