Thanks for the detailed, yet slightly worrying answer.
Welcome to the long running back and forth over BC.
I wonder though, since you're talking about stutter, hence I assume we're in the tens, maybe hundreds of milliseconds range, whether some kind of hybrid workaround would be feasible: again, totally (un)educated guess on my part, but would developers NOT willing to fully recompile their games be able to implement some kind of pre-run on-the-fly recompilation of the shaders?
I doubt it. Most devs are working in something like Unreal, which is hiding the Nintendo SDK from them. And the shader code, even. Lots of devs are making shaders inside an Unreal blueprint, but couldn't write actual shader language to save their lives. Adding this kind of pre-launch step would require engine support, which would in turn likely require a project rebuild.
What might happen is that Nintendo, when it detects a Switch game being launched, tries to scan the game for shaders and pre-compile them in the background. For something like a Unity or Unreal game, detecting the shader is probably fairly easy. But essentially you'd need to write this sort of detection tool over and over again for each engine.
Microsoft did something similar for 360 games, which don't have compatible shaders with the Xbox One. Except that they did it on the cloud side, which allowed them to ship out shaders in compiled blobs.
Does this even make sense? Sorry if it sounds dumb, I'm just trying to picture what could end up being the actual solution for backwards compatibility.
It doesn't sound dumb, it's pretty common in PC land.
I think the strategy would look like this, but this is just me speculating. At base you'd get exactly what you mentioned in the beginning, a compatibility layer the maps a Maxwell driver call to an Ampere driver call. That kind of monkeypatching is everywhere in emulator land, and isn't hard so much as tedious, but Nintendo and Nvidia know where all the bodies are buried.
When it comes to shaders I can see a tiered strategy. The bottom tier is a shader transpiler that just tries to be really fast. The Maxwell and Ampere ISAs aren't compatible but they are related, so the whole decompile/recompile process that PC emulation uses can be skipped for a much simpler, quicker strategy. Switch NG is 8 cores, Switch was 4, that leaves you with a dedicated core for transpilation. Switch NG has faster memory, though with small shaders, that's not a huge advantage.
The middle tier might be some sort of aggressive strategy to find shaders before they're invoked - try to detect them when read off storage for example, or like I suggested, scan the whole game for shaders. The key is you don't want to scan through 16GB of data on startup looking for shaders, then precompile all of them before the game launches, which would make startup potentially take minutes or hours, but you do want to grab them before they're needed
And the top tier might be some sort of pre-seeded shader cache that Nintendo distributes, either in the OS or as game patches. Expect Nintendo to triage this heavily, moving devs to next-gen patches where the games are well supported, and to give little attention to the poorly supported games that live right above shovelware on the eShop.