It used to be the case that coldfire was just not compatible enough with M68K object code, not so much because of missing opcodes (which can always be trapped, even if it means a hit) but that there were cases where instructions behaved differently without generating a trap. They were the real killers, since they'd introduce behaviour that would be unexpected and also impossible to work around. As far as I know, these compatibility issues have been mitigated in more recent cores since, though I don't know the technical details as I've not been keeping up.
However, assuming you can make m68k object code run, one oft-cited objection towards coldfire is that for full M68K compatibility you are potentially looking at a big performance hit relative to "native" coldfire code due to whatever emulation work is required to achieve compatibility.
However, how bad is that worst-case performance compared to say 030, which seems to be all that's presently on offer for new accelerator cards?
If it turns out that worst trap-and-emulate required m68k code runs at speeds comparable to a fast 030, or higher, then it is almost a bit of a no-brainer. Not all m68k object code you throw at it is going to be riddled with unimplemented operations and addressing modes.
When the 060 came out for amiga, trap-and-emulate caused a lot of performance issues, but things like CyberPatcher and OxyPatcher demonstrated there are faster solutions than naive trap/emulate.
