There are other frontends, yes. There’s Alcaro’s minir, Kodi’s retroplayer thing, GNOME Games’ player, Emulatron, ArcanFE, New Retro Arcade… probably some others I’m not thinking of right now. However, there is a distinction between frontends, like the ones I mentioned, and launchers, like Hyperspin, Launchbox and EmulationStation. Libretro frontends actually do a lot of low-level work, taking the video frames and audio samples from the libretro core and presenting them to the user. Launchers just launch the actual frontend and pass arguments via the actual frontend’s command line interface. They don’t do anything low-level and are just there to look pretty.
Libretro was designed with exactly what you described in mind. That is, the idea would be that programmers of different skillsets can stick to what they’re good at and everything is better and easier to maintain and people don’t get burned out supporting things they don’t really care about. Unfortunately, many emulator authors want to have tighter control over the user experience and/or don’t want to have their work subsumed into a multi-emulator package. That’s fine, of course, it just seems like a missed opportunity.
When RetroArch was first conceived, it was CLI-only and the plan was to let launchers do their part, cores do their part and the frontends do their part. Over time, though, we added more and more functionality to RetroArch such that it now bleeds over into the other areas, as well.
