It's got to execute the 68k gate, because it doesn't know what the code is doing. You can dynamically recompile it, but you've still got some lookups to do to find the native code.
It has to check if 68k gate is there: if it is then it can directly continue executing PPC code. If 68k gate is not found then system switches to 68k emulation. No need to dynamically recompile anything. The 68k gate is just 68k trap instruction and pointer to PPC code. Application writers dont have to care about it. It is all embedded into operating system.
Or you can put some heuristics in to find a standard gate and shortcut it. It's not just old libraries that this would have to happen for if you want to be able to drop ppc libraries in and have them used by 68k software. It could be any library that has ever been written.
Calling PPC code from 68k is really simple and extremely efficient. All PPC native 68k ABI calls have 68k gate with 68k trap instruction. When trap instruction is executed emulator switches to direct PPC execution mode.
It is easier than you think.
You can write libraries completely in C, I wouldn't like to say how often in occurred but you don't need assembler at all (just compiler support for regparm).
All 68k libraries written in C I have ever seen always use some reg(a0, foobar) style argument passing which will not work on non-68k compilers.
The next problem is that we're actually talking about x86 not PPC. So all of your code is going to have to do endian conversions. You either go the amithlon route, but then software that needs to write little endian values will end up doing two conversions. Or you spend the rest of time changing code to do the conversion where necessary. Or you try to come up with a new compiler patch that allows you to selectively have little or big endian variables.
Endian conversion of course is real issue on x86 it will be faster than WinUAE or any real Amiga.
Because of the amount of effort, still being limited to single processor and no memory protection, how horrible all the compromises would be to get it working on x86 it's not going to happen. I can't see developers flocking to an operating system that is crippled with that amount of backward compatibility. You can't even support x64.
Of course cant and if MorphOS switched arch it would most likely drop all 68k (and PPC) binary compatibility including use of 68k gates.