I have on my GitHub what I think is a simpler variant of this.

I implemented a dual architecture wine, that runs the wineserver natively and has native EXEs available, but allows running x86 binaries.

It (mostly) doesn’t share any pointers between architectures so there’s no thunking at the windows layer. It’s basically a very small patch to wine to allow wine to handle multiple exe architectures at once, and a method of compiling both a native arch and Intel wine into the same prefix and picking between them when an exe is executed.

For performance I have a method for thunking alsa and OpenGL to native libraries at the Linux layer, as well as an ABI compatible desktop OpenGL implementation using ES as the backend.

I am impressed:https://www.youtube.com/embed/mh4-Zz1uWaQ?feature=oembed

It was 7 years ago... why didn't you try to upstream it?

The library thunking stuff wasn't included in any of the projects involved, so I couldn't upstream that. My glshim project was most of the work involved and is still around and still capable of proxying opengl through a usermode emulator, and rendering fixed function GL via GL ES or software rendering.

My performance changes to QEMU would definitely not have been accepted based on sentiment when talking to the QEMU core team at the time.

My changes to WINE were extremely minimal (read the commits) and don't make sense to live in WINE unless you mash together a dual arch WINE distribution in the exact same, manual, way I did, so they don't make much sense to upstream.

A sort of spiritual successor to my work here is https://github.com/ptitSeb/box86 which is more like the OP and does HLE.