Depends how you do it. There's a messy workaround way of doing it, and a straightforward clean way of doing it (which requires much less processing). The messy way (which is most common) is to get it to read the file in its original format, translate the code, and recompile it in the new format in real-time. (this does take a lot of power to do, so is extremely slow and buggy). This method definitely does require alot more processing power in order to handle it, and is most likely to just crash if the hardware was not powerful enough to handle it, because it's trying to chug through parsing and compiling alot more data on each iteration all at once in real-time. Many PC based emulators do it this way, because it's easier for the programmer to do, but it's wasteful, so is a really sloppy way to encode it. (Most PCs can handle all these extra wasted steps though if it's powerful enough, so it's not so big of an issue in that context, which is why you will most often see the simpler but lazier method used). But you're right, as the switch is designed for purpose, they most likely haven't allowed for all that extra power. (Come to think of it, the graphics chip may not be able to handle simultaneous video output either for the two screens, so probably still wouldn't work).
But assuming you didn't have the graphics card problem, and were designing it for two comparably powered pieces of hardware. Here is the clean way of doing it, that doesn't require all that extra processing...
The clean way to do it from a coding standpoint that totally eliminates all that superfluous extra reinterpreting/recompiling.etc, is to simply build the emulator as a software based OS in and of itself. (The difference is, you would build this so that it instead reads the code in its native language in its already pre-compiled state, without having to interpret or recompile anything). The bit you would have to redesign for that OS though would be the hardware driver mapping layer. You would basically need to reconfigure that layer so that each natively read function directly calls the machine addresses of the drivers from your new hardware, instead of the drivers it would have called from the hardware it was originally designed for. Creating this OS would indeed need testing for bugs when building it. (and would still probably be wise to test individual games aswell, so that you can catch any unforeseen errors).
But as all this is not likely to happen anyway for the Switch given its graphics limitations, all this is kind of irrelevant now. (I just thought it would be an interesting topic to discuss). Being as you mentioned that you're getting back into games programming again, I thought you might find it useful if I shared some of this (in case you found it helpful to share programming techniques from eachother that we've each picked up along the way). -I don't want to come off as patronizing though (and it's also possible that you know plenty of stuff that I don't). Most of what I have learned has been from my experience in a PC based context, so it is entirely possible that some of these concepts may not necessarily be transferable in a console based context. (So if you do happen to spot anything like that which you know for a fact won't work in the way I have explained, then please feel free to chime in and correct me). New knowledge is always useful, so will never be considered patronizing, and is always welcome.
