I'm gonna give you the long ass answer to your question, as Dakhil already gave you the concise (correct) one.
The shader situation is well understood, and the Lapsus$ hack heavily suggests that they are both right about the shader situation.
This would be a book. Seriously, this is a get your PhD in compsci level question. Those systems use multiple BC technologies. But the one you probably care about is how are they compatible with PS4 shaders, and the answer is that they didn't break backwards compatibility when they designed the newer GPUs. They kept the hardware from the PS4 era to execute old shader instructions that modern games don't need anymore.
Rosetta 2 is a binary translator which monkey patches API calls. Here are two key points when talking about PC backwards compat:
PC apps never talk to the GPU directly, console games do. If PCs let random apps touch the GPU not only would you be infected with viruses that take over your screen, every random app could cause the entire system to crash. Minimize a calculator window and forget about it? Well, if it crashes your whole system reboots! Consoles are a different world, so console games get raw hardware access, for extra performance
This is why Rosetta 2 doesn't have to emulate a GPU at all.
PC games don't have precompiled shaders, console games do: When you change a tiny detail about a graphics card, you have to recompile your shaders. There is no way for PC games to do this for every combination that already exists, and even if they did, they wouldn't support new hardware. So PC games don't ship precompiled shaders, they ship the raw shader code, and your PC compiles it when it needs it.
Consoles are a single target, so it is feasible to ship precompiled shaders. This has big performance benefits. If you've heard of #stutterstruggle this is what they're talking about, and why consoles don't have it. But it is also why console games don't "just work" without changes on different GPUs
Rosetta runs on the CPU. It reads the code from an old program, dynamically retranslating as it goes, and then feeds the retranslated instructions back out to the CPU. In essence, the CPU doesn't even see the emulated program, it only sees Rosetta. Meanwhile, Rosetta only has to read tiny chunks of the emulated program at a time, very quickly recompile it, and send it on in tiny, fast bursts. Lots of CPU code is repetitive, going around in loops, so many times, Rosetta doesn't even have to do anything, because it has already recompiled the code.
GPUs don't work that way. There is no way to run something like Rosetta on the GPU, and even if it could, it wouldn't matter, because the game runs on the CPU. Shaders are GPU programs that get squirted over to the GPU in individul blobs, and are usually run immediately.
The way a Rosetta for Shaders would work, is it would run on the CPU, load up games into a kind of container where the game couldn't directly access the GPU. It would then intercept shaders, recompile them for the new architecture, and then squirt them over to the GPU itself.
This could work, emulators do it all the time. But it would introduce #stutterstruggle to the console games. Emulators try to work around this stutter, but they are 1) not completely successful and 2) it requires huge computing resources that Drake won't have.
Sorta? But it doesn't matter much, only the shaders are a tricky problem.
No, but again, only the shaders are tricky.
Console talk directly to the GPU. That means that each game basically builds in its own driver. Drivers need to know stuff like where physically on the chip parts of the GPU are, or exactly how many of component X or Y are, or the magic value of Q that only works on that chip.
Fortunately, even if every single one of these is different between TX1 and Drake, you don't need a complex emulator, you just need a remapper. If a Switch game wants to send command 0x800DBA14 to interrupt 0xD01E2A3D then all that drake has to do is catch it, and then look up those locations.
"Hmm, command 0x800DBA14 on TX1 is 'add' and interrupt 0xD01E2A3D is the first SM. My first SM is at 0xD02E3A0D, and my add command is 0x800DBA11. Let me just substitute one for the other it will Just Work"
Ampere and Maxwell are similar enough for this sort of technique to work. Driver emulation is simple and fast.
It's the shaders that are tricky, for the reasons I talked about before. Shaders are complicated, they're basically whole programs. Ampere might add an instruction that does what took 5 instructions before, while deleting 4 of those old useless instructions, which might take 2 new instructions to fake. Doing that translation is complex and slow.
You can't really partially emulate anything the way you mean, but you can essentially "pass through" the parts the are identical. Your emulator always has to sit in the middle of the whole thing, and you pay a performance cost for that. But when two systems are very very similar, your emulator only has to work hard at the differences.
But again, Shader recompilation isn't emulation in that way. That is why it is tricky
SM3DAS could do all these recompilation steps in advance, on a developer's powerful workstation. Drake has to do it in real time, using nothing but a fancy tablet.
SM3DAS's team had access to the raw source code of the original games, and could patch it if they wanted. Drake has to work with on every Switch game without every seeing the source code, and without ever changing it.
SM3DAS only had to work with 3 games, and doesn't have to emulate any features those games didn't use. Drake has to emulate every bit of the Switch hardware that any game uses.
SM3DAS's emulation only needed to reach the speed of the Wii, to run a 16 year old game. SM3DAS's emulation needs to reach the power of the Switch, to run games that haven't released yet.