This problem is far more difficult to solve than x64 windows apps running on x64 linux.

While x64 and ARM are both turing complete and thus anything one can do, the other can also do, there can be subtle differences to the way they do them.

Like one I’m aware of is the atomicity of loading memory using a co-processor register, which is required for accessing thread local storage, and introduces a subtle race condition if someone uses user mode multithreading (which can be way faster than kernel mode multithreading) without handling the case where they get preempted between moving that register’s value and doing the load, and end up running on a different kernel thread when they get back (because you need one kernel thread per core). That thread would end up with the pointer for another thread’s thread local storage, which tends to break things pretty badly.

That’s just one that I’m aware of. There’s probably tons of other subtle differences that mean you can’t just have a map of “x in x64 means y in ARM” and use that to generate a compatible binary. It would probably run, but it would have bugs that the original doesn’t that are only seen in rare edge cases.

Not that I want to discourage this effort, but this is a problem an order of magnitude or two more difficult than the one proton solved, which was essentially just a bunch of wrappers that convert one API or OS behaviour to another equivalent one.