The page we're discussing here actually says you can't mix arm64 and amd64 code in a single process, if your binary is amd64 all your libraries will be too. I'd be surprised if they put in the work to generate thunks for all their system libraries and then didn't make it possible to use any others. More likely macOS will just have two copies of all the (non-iOS) libraries and the only point they work together is the kernel since that's a nice clear barrier.
If I read it correctly, it says it prevents you from doing that, “including all code modules that the process loads dynamically”, but I don’t think that means Rosetta won’t call arm64 libraries for libraries linked at program startup.
Think about it: Rosetta translates your code to arm64, and your code calls a function in a system library. Why would Rosetta use the x64 version of the library and translate its code to arm64 if an arm64 version is available? there may be ABI differences that aren’t trivial to correct for, but for expensive calls, I would think that’s dwarfed by the gains of running native code.
Certainly, how is this going to run the Accelerate framework API at decent speed, given the emulator doesn’t emulate AVX, AVX2, and AVX512?
I imagine the answer is going to be that it doesn't. Stuff using Accelerate will probably see the biggest performance hit because it _doesn't_ use the arm64 version and the emulator translates those instructions poorly. However, since those are the applications hit the hardest by this switch they'll (hopefully) be some of the first recompiled for the new CPUs as well.
