Retroarch! It was built using .configure without any parameters defined, to essentially have EVERY possible feature installed. Yes, this makes it bloated and huge. My reasoning for this is, it also makes it an open canvas to test out EVERYTHING. The stock setup had a lot of things disabled; as you would as common practice. This included the XMB menu, which I am extremely fond of. This makes sense, given the previous state of the Lima drivers, essentially making the menu run like a crawl, and overheat the CPU like crazy. Not ideal. Since this was disabled for legacy reasons, i had no idea what else may have also suffered the same fate; thus why not have them all active?
You may notice also, I have copied the entire directory over to .config, including the build directories, and all scripts etc. This is so you can potentially rebuild it yourself as you see fit. It is completely redundant, seeing as I have it installed to the /usr/local/bin directory. The only thing really that is important is the config file, and the directory references to shaders/filters etc that would have needed to be manually moved to /.config/retroarch anyway. I moved the entire build directory over to allow you to have access to every possible thing.
Now. Onto how you can harness the power of the XMB! The first thing I want to point out is that I have altered the file structure of the gameshell rom directories heavily. I found it redundant to have different emulators of the same system refer to different rom directories. I also found it silly to have say gpSP+ refer to a directory called GPSP, as opposed to GBA for containing GBA roms. So I altered all the action.config files to refer to such directories. This directory structure is the same as what a stock retroarch (especially on a retropie) would expect. I did this to make synchronising games/save files between my rpi devices and the cpi more of a 1:1 experience.
With this directory audit also came the location of the retroarch SO files. The stock 0.5 image had them contained in /apps/emulators. The only things I keep in there are standalone emulators.
The problem with the stock 0.5 retroarch installation was that you couldn’t really use it to directly load games, since it didn’t have any directory properly defined for cores. It’s almost like the gameshell wasn’t intended to be used with retroarch as a base; but simply as a SO launcher. Not my cup of tea.
Part of the online updater in retroarch involves doing an “update core info files” - essentially the equivalent of an apt update. This populates whatever you have defined as your core directory with hundreds of .info files, dependent on where you have defined your builedbot URL. Oh so this is embarrassing. The builedbot URL in the version you are using has a typo! It is currently https://buildbot.libretro.com/nightly/linux/arm7-neon-hf/latest/ but should be https://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/
I put arm7 instead of armv7. Anyway, either download my updated config, or edit the config file (in .config/retroarch) yourself. (a side note: My laptop is a European model, and thus doesn’t have a tilde key lol. It has a ± in its place. Just assume that I’m putting in the tilde/ before .config)
If I had retroarch refer to the /apps/emulators directory, ie where the SO files are stored by default, you can see how this directory would get flooded very quickly, using the retroarch online updater. As it is set in this OS, retroarch now shares the same locations as the launcher action.config files where applicable. You can download more retroarch cores, and they will be accessible. I have downloaded all of the stock ones in advance. There is a way to manage the cores via the gameshell settings menu, ie core management. Essentially you could delete cores via the gameshell. I originally had to edit the *.py file in /launcher/Menu/settings to reflect my directory change. Unfortunately, this got overwritten in the latest launcher update, and I forgot to restore it. Perhaps I should make a custom line in the script to reapply all my *.py changes. You’re getting me thinking!
The core files are up to date, as of the build date, and running. I have chosen to do this, since future updates to the buildbot repository could see new SO’s that are incompatible with the gameshell, since the stock 0.5 image downloads them on demand.
Now! Just using the XMB interface, you can choose to “Load Content”, and then choose whatever core you want to be the one associated on the ROM. It’s on a per rom basis, and has a list file defining this. It will come up with a list according to what cores you have installed, so go absolutely wild downloading extra cores via the online update>core updater. You can redefine what core your rom uses at any time.
The real beauty of the retroarch XMB interface comes in the form of the playlists function. It will produce a beautiful list, sorted into graphical directories of each of your roms. In addition it will also provide box art, a thumbnail of the title screen, and possibly extra information. You will need to the + sign in the retroarch launcher, and scan your rom directory in order to populate these lists. I like to store all my roms in *.7z and *.zip archives. This scans within these, listing each file contained. Great for when an archive contains a bunch of language, and the first one loaded by default is one you don’t understand! For this reason, scanning can take… hours. I leave mine overnight. This is the reason my first gameshell has an extremely washed out display. 
Believe it or not, retroarch WILL in fact magically work, detecting the ROMs in the correct places. It identifies the extensions of the files, and then scrapes the appropriate information it sees them. The only setup is really initiating a scan. In fact, I’m wondering whether or not changing my directory structure to match the file extension, as opposed to the emulator used has anything to do with how it seamlessly integrates and just works.
The only reason I kept up with Retroarch development etc is fact that I delved fairly deeply into the raspberry pi development side of things. That’s actually what I was doing that made me discover the gameshell. I’ve basically jumped boats.
Anyway, I don’t think there’s much else to really say re: how to use it. In theory it should all just be very self explanatory. Just watch out re: stability. Not just in my build, but even in the stock 0.5, there have been reports of retroarch just crashing loading roms. Thankfully just booting back to the launcher, but a bug nonetheless.