A fair response, although I might quibble with your choice of the term "moron"; if that was what I thought, I doubt I'd have bothered replying to you at all.

(I note also that, in my earlier reply, I forgot to mention that several Foobar2000 users have requested better self-signed cert support from Pawlowski, whom I've never seen to respond favorably to such a request. I saw little value in registering for the HydrogenAudio forums, solely in order to weigh in on the side of a feature which the developer plainly doesn't consider worth his while to add.)

I've never seen a playback queue as anything other than possibly an imperfect workaround for the limitations imposed by the inability of playlists to contain nodes pointing to other playlists, and my frustration around the subject of Foobar's playback queue stems from the fact that it's not even any good at that, much less at being a good idea in its own right -- the fact that the queue's contents aren't even exposed in the UI without adding a plugin should, I concede, have served as a strong clue. (And your choice of Perlis' epigram strikes me as truly inspired! Why, indeed, should we have these two things, the playlist and the playback queue, which behave similarly but not identically, and whose coexistence requires a bunch of otherwise unnecessary special cases?)

I can appreciate your incredulity at playback queue (mis)behavior being a deal-breaker for anyone with foobar2000; annoying as I find those idiosyncrasies, they don't rise to that level. The brokenness around self-signed SSL certs does, though, because it makes the player effectively unusable for my purposes anywhere but at home -- hardly, I think, something which qualifies my abandonment of foobar2000 for streaming use as "throwing the baby out with the bathwater".

It's funny you should mention "the child of Emacs and foobar"; as it happens, there is a music-player integration package [1] for Emacs, which I've occasionally considered trying out since that is the editor I use. Unfortunately, EMMS doesn't appear to support FLAC/CUE-per-album, which I regard as a sine qua non since so much of my library is in that format.

Given the increasingly solid multimedia support in modern browsers, and given also the existence of a pure-Javascript FLAC decoding library [2] which has worked surprisingly nicely in my trials, I've lately been mulling over the thought of writing my own relatively simple-minded player, which I could host in the same place as my music library and just fire up in a browser when I wanted to use it -- and which, yes, would support adding playlists to playlists, and be able to shuffle among playlist nodes in a sensible way. By succeeding in such an effort, I could both satisfy my own desire for a particular combination of features, and make a very convincing public argument for my belief that the current style of user interaction around music playlists is neither the last nor the best word on the matter.

On that note, I appreciate your taking the time to argue with me in this thread; any opportunity to refine my thinking, on any subject, is of value.

[1]: https://www.gnu.org/software/emms/

[2]: http://badassjs.com/post/25174050115/flac-js-aurora-and-the-...