We'll see, but I doubt it.

A user-level emulator is a completely different beast performance wise than a full system emulator. With a user-level emulator the kernel, and possibly even the shared libraries are native code, and the code that needs to be emulated is relatively easy to translate from one architecture to another.

For a full system emulator not only you need to emulate the kernel also, but all the system-levels instructions have to be emulated as well (unlike user space instruction that can be JITed).

Just compare the performance of qemu-system-aarch64 with qemu-aarch64 running on amd64, and you will see a MASSIVE difference in performance. It's very likely rosetta will be more optimised than qemu, but still there is a fundamental problem here.

I'm sure qemu-system-x86_64 will run on aarch64 macs, but I doubt Apple/Parallels/VMware will touch this space.

Fair points, and on reflection you are probably correct.

But Apple has a history of weird but successful systems that nobody else tried, like 64 bit user space with a 32 bit kernel, or mixed-endian processes sharing memory. And there's pointed coyness around "Apple Silicon" and Parallels keeping mum. So I want to believe.

I need to believe because it makes a massive difference for me as an embedded developer. I can't use Macs anymore if I can't run multiple x64/x86 Linux VMs on them.

When did Apple do the mixed-endian processes? Was this with PowerPC Macs?

It would be interesting to see a blend of Rosetta2 for translating and running user-space x64 code and a WSL-style kernel "shim" to provide direct access to the native aarch64 Darwin kernel.