What the Switch 2 is using for backwards compatibility is almost certainly Nvidia's Unified Driver Architecture. Also known as UDA.
Before the UDA every GPU needed specific drivers. It was not like it is now where you download one package for most/all GPUs. You had to get a specific driver package from the vendor, for that specific model of GPU. This is the pre nVidia/early nVidia days of Voodoo, ATI, Riva, etc.
The UDA uses a number of methods to make drivers universal among multiple models/vendors/generations. Including a Hardware Abstraction Layer(HAL), Unified Instruction Set, and more. This not really emulation. This is using translations layers. But also more. The two components I mentioned are the ones we'll get into.
Quick sidenote: CUDA(as in CUDA cores) stands for Compute Unified Device Architecture. It was a huge advance in parallel processing. This is what allows stuff like Folding At Home, etc. We don't need to get deep into that though.
Something important to understand is how integrally the UDA is a core part of Nvidia's hardware and driver architecture. I don't think it could be removed if they wanted to for some reason. Nintendo using Nvidia Hardware has given them a unique advantage when it comes to backwards compatibility when it comes to consoles. The UDA allows Nintendo to break the traditional paradigms of console backwards compatibility.
In the past each hardware generation for a console used such highly customized hardware that this kind of backwards compatibility was not possible until now. As consoles become more like PCs, backwards compatibility will overall become easier. As an example the Wii U used customized PowerPC architecture(almost no one uses it anymore.) This is why you can't have Wii U backwards compatibility on the OG Switch. (AMD does have their own version of the UDA. Consoles made with AMD hardware have been too highly customized until the most recent generations to make backwards compatibility as easy)
With the Switch to Switch 2 they're both on Nvidia's Tegra/ARM architecture. With Nvidia's UDA, because it's core part of how Nvidia does these things. This means that backwards compatibility is a lot easier. Although not necessarily automatic. How easy it is and so on has a lot of "it depends" going on.
Now let's get into some of how the HAL and Unified Instruction Set I mentioned previously work.
The Unified Instruction Set is more or less what it sounds like. This of course makes things easier in general. Even several generations apart, the Switch 1 and 2 will use many of the same instructions. But not all of them will be the same. This is where translation layers and the HAL come into play.
The Hardware Abstraction Layer is different from something like Proton/WINE,* and also similar. Proton/WINE operate at a software level. The HAL is at the hardware level. This allows instructions that aren't native to that hardware to be translated into something the hardware can understand.
*WINE stands for "Wine Is Not an Emulator." Proton is based on WINE.
A lot of why games may need some patching to run fully properly on Switch 2 can be variable. Most of it overall comes down to software for the OG Switch was coded and optimized for the Switch 1, with Switch 1 specific tools. This is where we get into "it depends" kind of stuff. It's fairly likely that there will some common causes of issues with backwards compatibility in Switch games. It could be a specific call/instruction that has a bug/issue on the Switch 2 only as an example.
In contrast, PC Games are made with tools already geared towards a wide variety of hardware. Even then there are often issues with PC Games tied to specific GPUs/drivers/etc that require patches. PCs and PC Games are not free from issues with backwards/forwards compatibility. PC is simply a different paradigm that we don't think about the same way as gaming consoles.
Something that was mentioned early on in Switch 2 backwards compatibility discussions is that the driver package is part of the software when it comes to Switch games. This could be part of why some games need some extra patching. Of which that patch could possibly be more or less equivalent to a driver update. Although the HAL is meant to handle stuff like this, there are limits of course.
Another issue scenario that I'll speculate at is the whacky vsync buffering used in some games. TotK and Echoes of Wisdom are prime examples. What happens is the framerate tries to lock to 15/40/45/60 depending on what it's closest to. The trouble happens when the framerate fluctuates close the point where it switches which one it locks to. With a VRR display that supports 120hz you at the very least want to turn that vsync behavior off.(Mods for emulation that turned that vsync buffering thing off are common in games where it an issue.)
This is already a long enough mini essay so I'll wrap this up with a TL;DR style summary:
The Nvidia UDA has been around since the early 2000's and is taken for granted/forgotten about. Overall consoles are more like PCs which overall enables easier backwards compatibility. On top of that Nintendo has a unique advantage in sticking with Nvidia hardware, specifically the Tegra ARM SoC's. Because of the UDA, most of the serious and difficult work is already done by NVidia when it comes to backwards compatibility. This breaks the traditional paradigms of gaming consoles.
This not emulation, and more than a translation layer like WINE/Proton. There are multiple components at work. The Hardware Abstraction Layer and Unified Instruction Set are only 2 of them. The UDA is integral at all levels, it's in the hardware and drivers. It does have limits, and even on PC it's not perfect. It makes backwards much compatibility easier than it has been in the past for consoles. Although not automatic or flawless, it depends.
