I had my own crazy idea for co-opting the 68K, but I am not really sure how practical it is. Probably entirely impractical. However, if we note for a moment that it can read and write all the same address space the PPC can, then we could envisage it as a programmable DMA controller for motherboard resources, such as the IDE, PCMCIA etc. In this scenario, it has a small work area reserved for it (unpageable from the PPC side) that it can cache (for code and small amount of working set), but otherwise it regards the rest of the address space as uncacheable. It could then be invoked to transfer data to/from legacy devices independently of the PPC. From the latter's perspective, you'd obviously need to do the Pre/Post DMA calls for regions affected by any operation you intend to perform. Uncached memory access from the 68K would be suboptimal, but at the same time faster than any of the IO devices it would be talking to, so they'd almost always be the bottleneck. For a lot of block stuff, with luck, you could use move16, thus avoiding cache pollution so that your 68K manages to keep it's local working data and code in it's cache, avoiding unwanted memory accesses that aren't part of the transfer you are performing.
Of course, this nebulous hand-wavy description overlooks many important technical details (arbitrated access to the "DMA controller", interrupt control, scheduling etc), though I see it as being slightly less complicated than trying to actually use the 68K for running actual 68K applications under any kind of inverted WarpOS scenario.
