So I have at least some inkling of what’s going on here now. After lots of poking around I have what I believe is a firm grasp of at least how the system here works:

First you have the config in /opt/retropie/configs/all/retroarch.cfg – I will refer to this as the “baseconfig”.

Then you have your controller configs located in /opt/retropie/configs/all/retroarch-joypads – I will refer to these as “stickconfigs”.

Lastly you have configurations located in /opt/retropie/configs/emulators/{system name here}/retroarch.cfg

Here is where it gets tricky. Each of these files is mostly empty and the last line is #include /opt/retropie/configs/all/retroarch.cfg

So when you boot up an emulator it looks at its configuration, and (as far as I can tell), it then parses custom configs, THEN it grabs a copy of the baseconfig, and includes it for configuration, before (possibly?) grabbing the stickconfigs and including those.

So I’m pretty sure there’s a bug here, because making per-emulator changes to /opt/retropie/configs/{emulatedsystem}/retroarch.cfg was not working for me, I believe because the baseconfig file is being loaded after the file that’s supposed be be containing “overrides”.

So even if I put “blah_thing_btn = x” in /opt/retropie/configs/{system}/retroarch.cfg, it would just immediately get stomped over by the baseconfig (and/or the stickconfig) getting included as a later part of the config loading chain.

Maybe I never correctly set a necessary flag, or this is a bug; I haven’t experimented enough to find out which, and I don’t really have the time to :( – sorry! I’m just documenting this in case it helps others or helps the devs bugfix.

So my solution for emulators where I want to alter the “stock” config: rename /opt/retropie/configs/{system}/retroarch.cfg to something else, and then copy the baseconfig file to that same directory and make necessary modifications there. Without the #include taking place you don’t have to worry about your per core changes getting stomped over!

It’s a brute force way to solve the problem, but as I said, I wasn’t really interested in putting in a ton of time into tracing the config hierarchy and determining what was *actually* taking precedence and being loaded in what order and then working around that. I can confirm this method does work for me, and I’m happy with it, so I don’t intend to do a lot of global tweaks from here on out.

I hope this helps anyone interested! Feel free to use this information anywhere helpful (wiki, etc) if someone wants to write up a summary/guide on the basic flow for loading configs, since I couldn’t find it documented clearly on the Wiki (though it may be there and I just never found or understood it)…