Hey, thanks for the constructive input!
I’ll answer the questions I can:
Q1.) why are emulators called cores
A1.) because not all of them are emulators. We have cores for a variety of different tasks, including video players, image viewer, 3D model viewer, standalone games, etc. Calling them all emulators wouldn’t make sense, and we don’t want to tie the ecosystem down artificially, since emulators are merely a good fit for the API rather than the only thing it can do.
Q2.) why is each version of a core listed?
A2.) related to A1, we don’t want to make our frontend favor any specific core or family of cores, so we are careful not to hardcode anything having to do with emulators or specific consoles, etc.
Q3.) Why no icons when selecting cores?
A3.) Dunno, this would be a good question for @kivutar.
Q4.) why so many steps for setup? Why not automate it?
A4.) Not everyone is looking for a Hyperspin-style frontend experience with boxart, etc. RetroArch is focused on modularity, so while we’ve tried to supply things like boxart and support for large collections, we don’t want to force it on anyone who prefers a more spartan setup (I, for example, don’t use playlists at all, except for testing purposes, and don’t use boxart/thumbnails).
Q5.) why not include the cores and autoselect the best one for the job?
A6.) the various licenses involved in the myriad cores don’t always allow the distribution with other dissimilarly licensed cores, so having the user separately handle that is a way to keep everything above-board legally. As for autoselecting, my own feeling is that we want to provide a platform for cores from various people and it’s not our job to identify winners and losers (i.e., I can just see the drama unfolding from $emu_author’s core getting bumped out of the “suggested” spot by some other core). There are some n00b-trap cores that I think we should stop including on the buildbot, but for most things, there are reasons why you might want to use almost any of the cores on almost any platform.
Q6.) Why keep so many confusingly redundant cores in the list? <<you didn’t ask this one directly but I inferred
A6.) I agree that it’s confusing to have 5+ datestamped MAME and Snes9x cores and 2x of each bsnes core (for 6 total, not to mention mednafen-snes, which is yet another bsnes fork, and bsnes-c++98, which means nothing to non-programmers; both of these are in the “n00b-trap” camp, IMO). I’m not sure what can be done about it, though, without hardcoding things into the frontend and/or hiding cores (i.e., kingmaking).
For your suggested workflow, I like the idea of easily changing the sort filters. There was a reason why we stuck with downloading all of the thumbnails instead of just the ones we need but it’s eluding me right now. I think it was just slow and had too much network chatter overhead to check and download each one individually.