If it doesn't manage to autoconfigure the controller, you want to remap inputs or you're using a keyboard, you're in for some pain. The GUI doesn't show which actual physical button you're remapping core inputs to, only the RetroPad button. You have to keep in mind two levels of chained button mappings which is harder than it seems. If you remap the RetroPad itself you also remap the entire user interface inputs which leads to stupid situations where the GUI stops working and I have to edit the config file to undo whatever mistake I made that left the inputs in an inconsistent state such as two buttons mapped to the same key.
I actually argued with this guy on 4chan over this once many years ago. Why not have cores enumerate their inputs so that the frontend can map directly to them? SNES cores would return the symbols representing the buttons on the SNES pad. Something like this:
core.inputs.digital = [↑ ↓ ← → A B X Y L R START SELECT]
A few months ago I found Ares (https://ares-emu.net/), a fork of bsnes/higan with a pleasant UI and multi-system support, and I couldn't be happier. It is not perfect, but it is so much nicer.
I always have to remap inputs for nearly every game because I want to have my jump, attack, dash buttons and all the other inputs remain consistent for every game due to muscle memory. The mere existence of the RetroPad makes this nightmarishly hard.
It's not like he doesn't know this. I remember him committing features that would let people swap A/B and X/Y buttons precisely to help the arcade players. Who knows what he's done since then. Maybe he fixed it but I wouldn't bet on it.
> And don't get me started on the million different cores and forks of forks of forks.
Yeah, even the emulator authors themselves are unhappy with that. I guess RetroArch needs those forks because their audience includes people with underpowered devices.
RetroArch (the main libretro implementation as well as basically the reference implementation) is overengineered to the point of bordering on unusable. The entire project is riddled with bad design decisions for the sake of extreme modularity, but all this results in is that it's a pain in the neck to configure and customize. Remapping a button in an emulator, a relatively easy task for basically any emulator out there, can result in your entire setup breaking down and because your typical RA install has ~30k files and poor separation of configuration and application components, your only real recourse is to reinstall the entire thing.
Ironically, this specific deficiency also why most emulators nowadays have migrated over to using Stenzeks duckstation UI (which itself is based on Dolphins user interface, just better written); it turned out to be well written enough to be reusable across multiple emulators with fairly little modification, while also leaving developers the room to customize certain elements to fit their emulator (something which libretro is really bad at).
Libretro mostly got where it is because Twinaphex has enough orbiters to keep all the various cores up to date, even if it takes what amounts to a hostile fork to do so.