Wine should consider integrating some sort of emulation into their framework.
They’ve considered it a few times over the years. There was some work a while back to integrate QEMU for running Wine on PowerPC Macs. Wine isn’t really set up for doing this well though: they compile almost all of their code as native Windows DLLs and have thunks for going outside. You could put the emulation boundaries on those thunks, but then you’re not getting much more benefit than you would from running Wine in QEMU user mode. To do it well, you want to profile the Wine DLLs, find any entry points that do a non-trivial amount of CPU work, and put thunks on these boundaries so that they’re running optimised native code. This is what the Transitive emulator that Apple licensed for Rosetta did and in a lot of desktop applications spent 80% of its time in native code (all of the drawing routines, for example, were native). It’s probably quite difficult to retrofit that to the Wine codebase, where they’ve tried very hard not to have any kind of thunking at that layer (because it makes things much faster in the non-emulated case).
They’d have to change their name..
Wine (originally an acronym for “Wine Is Not an Emulator”) 
Wine (originally an acronym for “Wine Is Not an Emulator”)