Ah, thanks, that was a great and well-detailed reply.
That clears a few things up a bit for me, and helped me realize something about what you said in an earlier post: according to you, the G5 processors implemented the UISA (User ISA) in a PowerPC-compliant way, meaning Book I of the POWER / PowerPC formal specifications, but not necessarily the rest (Books II, III and E).
Since the User ISA is 100% compatible and implemented between G5 and earlier PowerPC processors such as G3 and G4, doesn't that actually mean that Mac OS 9, which, being an OS, runs entirely on user space (excluding the nanokernel, which you suggested should be looked at separately) and, thus, is also 100% instruction-compatible with the G5 processor?
Assuming the answer to the previous question to be "Yes.", we are left with the nanokernel which, according to you, is normally used by OS 9, but is completely disregarded or even missing altogether in regards to Classic in Mac OS X (XNU). If I understood you correctly, the instructions you believe to be missing in the G5, which are on non-user-space, are present only in OS 9's nanokernel and are most likely emulated within XNU if XNU is running in a machine that lacks the native instruction.
Since Classic is a common program/process/task like any other that runs under Mac OS X, which in turn runs in user space, and since Classic delegates all the nanokernel calls to the XNU kernel instead, that means Classic itself does not and can not, by itself, emulate any missing instruction, but rely on XNU for all its nanokernel needs, including emulation of non-UISA-instructions, if needed. Classic is then unlike, for example, Rosetta on x86, which emulates the PPC UISA in an x86 UISA environment. And Classic IS like Rosetta in the sense that all that both can hope to achieve is stuck at UISA level (AKA user space).
With all this, I mean to conclude that, necessarily, Classic is not at all relevant to us here in terms of processor architecture compatibility or lack thereof for OS 9: the XNU kernel is. Correct?
If correct, then my understanding is that to solve this processor architecture problem, an implementation on the OS 9 nanokernel is necessary to immitate whatever the XNU is doing in those cases. And the XNU only. Preferably Tiger's XNU as opposed to Leopard's, as it's the last XNU revision we know for sure that had a motive to bother keeping OS 9 nanokernel instruction compatibility. Which is not to say that Mac OS X itself necessarily didn't contain those very instructions themselves to be later emulated within the XNU on G5s.
(For emphasis, motherboard & other hardware drivers, though, are still entirely different subjects and dependencies than what I'm trying to get at here.)
All OS 9 nanokernel gurus out there and Naiw, please do correct me if I said some gibberish somewhere here. 
I'm kinda walking blindfolded on some areas, but doing my best with it.
There is one or two instructions that isn't in UISA on the G5, but it's handled by the kernel as said in the earlier post.
(Posted this link before, but this is from Xnus kernel source.
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.4.x/osfmk/ppc/Emulate64.s - it explicitly lists dcba and mcrxr)
dcba is data cache block allocate- it can safely be ignored (it's just an optimisation instruction)
mcrxr is move to condition register from XER - this has uses and I don't know why IBM choose not to implement it in hardware, mainly it's useful to detect overflows.
Other than that I don't think there is any that is normally software emulated (if at all).
Xnu does not attempt to make the G5 behave like a G3 or G4 at OEA level- there is no reason to, it only bothers with UISA (most of the code in the emulate64.s class I posted above is actually about handling unaligned data- not because the G5 lacks hardware support for those instructions, the PowerPC can't access memory that isn't word aligned without throwing an exception- most systems therefor handles this by emulating the instructions when an unalignment exception occurs- this come at a performance penalty of course which is why NewPtr etc on Mac OS always returns (16 byte, if I remember right) aligned pointers- This is partially due to Altivec though so I would guess pre Mac OS 8.6 NewPtr probably returned 4 byte aligned pointers)
No that's not right, Classic can absolutely emulate instructions, to be able to emulate an instruction your software must be able to catch invalid instruction exceptions and get hold of the register state, Mac OS X certainly provides the facilities to do so- So does Mac OS 8.6+ as well for that matter- but you can of course not alter all registers in the representation,
I actually often used that when I wrote classic Mac OS apps, mainly for debug purposes- as you could do something like "sc" which would trigger the system call exception handler- once in the handler you could modify the single step bit of the represented MSR and return, this would trigger single step exceptions for each instruction Mac OS executed for that particular process (the exception handler was per process, not globally on the system). There for you could implement a simple software memory protection that you activated selectively around certain portions of the code you wanted to "sandbox"... but it was of course at a huge performance hit, but it was in my opinion better than crashing and potentially risk file system corruption or worse.
Yes I agree Classic is of little interest if you want to run Mac OS 9 natively on the G5. At least I can't come up with any particular area it would be worth investigating, drivers etc are as you say just delegated to OS X- possibly the only area that could be interesting as I see it is to see how it interfaced with the USB bus, cause classic allowed mac os 9 drivers to own USB devices as far as I remember.
Leopard would do fine as well, you don't have to focus blindly on Classic... Mac OS X binaries have the exact same problems/caveats when it comes to UISA as Classic did.
Yes drivers are a totally different beast and probably a much harder one at that... I still stand by that I believe OpenFirmware can be kept around to just have _something_ working/booting.
