As used to as we are with Intel pushing the limits of integration, the 68K was a huge gamble using high-density short-channel NMOS (HMOS). I suspect that yields were pretty low and that the usual second-sources weren't ready to take the gamble.
I think it was WESCON where I got my hands on 68K documentation--this was the same WESCON where TI was giving away samples of the PACE, complete with documentation (Moto wasn't giving away samples of the 68K). Fairchild didn't want to talk to you about the 9440 unless you were in the defense industry, etc. The 8086 and Z8000 had been out for a while and got mostly yawns as being souped-up versions of the 8-bit CPUs.
The 68K was exciting--large, linear address space, generous in the register department, simple instruction set and--this one got everyone's notice--an asynchronous bus, in addition to "user" and "supervisor" modes of operation. That is, there is a "handshake" between the CPU and addressed devices, including memory. An address must be responded to with an acknowledge that the device being addressed actually existed. No acknowledge--you get a bus error trap on the CPU that throws you into the privileged supervisor mode.
What this meant was that a device or memory address not present would cause an error exception. Can you say "virtual memory"? One of the most-asked questions at that WESCON was "Can I use this to implement virtual memory?" In other words, if I get a Bus Error interrupt, is there enough information present for me (the supervisor-mode executive) to restart the instruction causing the error if I remedy the error condition?.
In short, "Can I run Unix on this chip?" (Usually meaning 4BSD) was a big item of interest.
Sadly, the answer was "not really--there are some instructions (mostly memory-to-memory) that cannot be restarted with the information provided by the BERR interrupt." I think that cost Motorola dearly--and they remedied the situation later in the 68K family. Some vendors (Apple, Apollo) went ahead anyway. Apple simply proscribed use of the instructions that couldn't be restarted; Apollo on their Domain workstations ran two 68000s; one that ran slightly ahead of the other--when the first got a bus error, the condition could be satisfied before the second CPU encountered it. Clever, but expensive.
The only other plausible contender at the time was National Semiconductor, who contracted out the design of a very advanced CPU, the NS32000 series. But the story was always "Real Soon Now" and the thing missed the boat completely by coming out too late--it later found embedded use in things needing lots of CPU such as laser printers. And National didn't have the best track record for support--it had lost interest in the SC/MP, then the PACE and the new CPU might well be next. NS was always better in the digital world at second-sourcing CPUs.
Intel, at the time, was involved in its own "Real Soon Now", the IA432--a hugely expensive "next generation" CPU chip set. The 8086 was initially intended only as a stopgap "bridge" product until the really serious people jumped on the 432 bandwagon.
So when IBM came out with the 9000 lab computer, you could almost taste the hope that the yet-to-be-annouced Personal Computer would use it. But that was extremely unlikely--IBM had already deployed the 8085-based Datamaster systems and the Displaywriter was 8086-based. That the PC would use Intel bits and pieces was never really in doubt--Intel could supply chips in quantity and I suspect IBM got a real sweetheart deal by incorporating other Intel chips in the contract. In fact, the early 5150s didn't use a NEC 765 floppy controller, but rather the Intel labeled clone--the 8272. Intel and NEC were involved in a number of cross-licensing deals--I've heard that Intel couldn't get the 8272 to work and so let NEC complete the job in exchange for manufacturing license for NEC's advanced display controller.
I don't think that the 6502 was even in the running. How would IBM have competed against the likes of Apple and Atari with yet another 6502 design? In particular, IBM had no interest in developing software for the PC intially. Trot the thing out, make the internals public right from the start; offer development tools and stand back and see what happens.