By the way, I didn't write the wrapper or anything, and don't know if it's there for some other reason. My guess is it was there for an earlier version of retroarch, or just because the author didn't know explicitly passing it was bad.

Also just in general, I don't think this wrapper is currently doing much. First, it adds each core to the LD_LIBRARY_PATH, which I'm not sure retroarch actually uses, and then passes the directory of cores to retroarch with -L, which in older versions of retroarch (<1.0) was used to override the core directory, but has been silently broken and deprecated since (they broke the functionality then removed it from the documentation). So in short, this wrapper builds specified cores, but doesn't actually pass them to retroarch in any meaningful way. I don't think removing the wrapper altogether is the right answer though, declarative building of cores is definitely the proper nixos way.

For a user wanting to use the nix built cores, a naive workaround would be to manually configure retroarch to point to /nix/store/<hash>-retroarch/lib, but then you need to update your config on each retroarch update. A slightly better approach for nix-env users could be pointing to the core directory in ~/.nix-profile/, but because the wrapper puts cores in /lib, they end up in .nix-profile/lib along with a ton of other shared libraries. This doesn't really make much sense, most other distros put it in a different directory like /usr/lib/retroarch, a much better directory choice might be /lib/libretro or /lib/retroarch. This way all the cores would end up in an isolated folder when merged into .nix-profile.

This feature (-L for core directory) was originally broken when they partially rewrote some related code, but remnants of the code for the feature still exist. I have also checked the code for what should happen when a directory is passed to -L, and currently it's a harmless no-op. So I think the best course of action is to continue passing -L as we are and attempt to fix this upstream.