It never ceases to amaze me how much free engineering effort is expended to work around Apple's resistance to open source and power user hostility.

I would argue that the fact that sort of work on reverse engineering Apple’s products happens so consistently suggests that in some capacity, current open options aren’t meeting the needs of some number of highly technical users, and that for these users having to expend the effort required to bend Apple products is more appealing than accepting the trade offs that come with more open options.

The only time I've ever used stuff like this for is to support macOS users when I don't have Apple hardware to test on, or to bootstrap a Hackintosh (also used solely for supporting others who actually like macOS) when I don't have ready access to Apple hardware.

I imagine that similar is true for many users of this project, although some others use it just to daily drive macOS on a configuration Apple doesn't sell.

The ARM CPU would still have to be emulated on x86_64, which would be ungodly slow.

There's no reason to believe this has to be slower than x86 on ARM

Well, emulating† x86 on ARM is excruciatingly slow, just as emulating ARM on x86 is (turns out I do both, routinely, so no need to believe when I have data: it's about an order of magnitude slower than native)

† Rosetta 2 is not emulation.

Emulating x86 is slow on ARM because it's inherently a less complex instruction set. Emulating things the other way around is dead-simple by comparison, it's what made it such a cakewalk to write Nintendo Switch emulators on x86. ARM has to swing up the abstraction chain to implement x86 instructions, whereas x86 can execute ARM instructions for cheap, free, or even faster than ARM natively in the case of SIMD calls.

Plus, that's ignoring how people will actually try to get MacOS running on these machines. Once x86 is finally considered "dead" and removed from the MacOS ecosystem, the solution is going to be kernel patching. It's hard to speculate on how difficult this might be, but I'd imagine that a small team could port binary patches from BSD to Nu-Mac fairly quickly. It's not a particularly complicated process, just a mite arduous.

This is generally not true. x86 has a bunch of CISCy instructions that translate to several ARM instructions, but ARM also has a bunch of things that encode strangely and split across several x86 instructions. In general, they're not that far apart in complexity. (There are instruction sets where this is true, e.g. older architectures like 6502 or whatever. But it's unlikely to be the case for anything moderately complex.)

Rosetta 2 is an emulator. It has a JIT compiler inside of it!