No, the 68008 was not even in sampling in time for the team that built the 5051. (The 68000 was in use by the team that built the Scientific 9000, but that was a project of different scale. Interesting that IBM later re-used the 9000 model number.)

Curious as to what you did to get drivers for the peripheral parts. Did you write those yourself? Also, what does the MCL68 do with odd bus error exceptions? Did you disable those when you folded the 68000's 16-bit bus into the 8088's 8-bit bus, or did you just make sure all the driver code used the MOVEP instruction?

My search foo didn't bring up any decent results for Gordon Bradley's 68K BASIC. Is there a technical comparison somewhere between the syntax and internals of that and Microsoft's implementation of their BASIC for the PC?

I ran the 8088 emulation code and simply snooped and stored all configuration writes that the IBM BIOS wrote to them, then carried them over to the new project.  Simple!   Sixteen bit accesses are always broken into two byte accesses, so no trouble there. Not sure about the 68K BASICs... 

JFTR, breaking 16-bit accesses into two byte accesses did not prevent the 68008, 68HC001, or  even the 68EC000 from taking the odd address exception when accessing 16-bit data on an odd address. I think it was the 68020 and above where the odd address exception was restricted to instruction access only.

Note that I don't think this affects your observations that much. Given a decent CPU from that time period, memory timing and size of address space were the overriding determinants of performance. With programs small enough to fit in 64K, the only thing left was memory timing. (Data bus width would have some observable effect, but 16-bit width would not even double performance.) So, yeah, we'd expect the performance to be close to similar, given the same memory and I/O. We'd be surprised if it weren't.

It doesn't really answer the alternate universe question of putting the 68000 in the original IBM PC, but it does establish a bit of a base line of expectations.

(The alternate universe question is not about the performance of the original IBM PC. It's about the expansion possibilities of linear addressing beyond 64K. IMO, of course.) 

Still a cool experiment. And snooping the accesses to get quick workable drivers, yeah, that's something I wasn't thinking about. Kudos.

Pretty cool, though if IBM would've chosen the 68k, they definitely wouldn't have used the 8080/5 peripheral chips :). Also, why IBM went with the 8088 as opposed to the 68k is widely documented, iirc the reasons were that it was still in development at the time, was quite expensive (ceramic 64-pins) and support chips were lacking. Otoh, the 8088 was readily available, relatively cheap, and the 8080/8085 support chips they ended up using were also readily available, proven technology and cheap.

Well-opined is probably more accurate than well-documented. Among other things, the 8-bit 68XX peripherals work just fine with the 68000. Intel's peripherals wouldn't have been that hard to glue in, either. Cost, well, maybe, but IBM was well aware how quickly prices would be brought down when sales ramped up.

Some of their projections got close to reality, and those projections were the ones that worried management the most. 

People's recollection of things are well-documented, see e.g. here: https://www.eejournal.com/article/how-the-intel-8088-got-its-bus/

For some reason, I can't reply directly to your comment with the eejournal opinion piece, but I suspect my earlier comment was too brief.

Let me try that again:

The 68000 had built-in support for 8-bit peripheral devices, both in the bus signals and the instruction set. Most of the popular implementations, including the Mac, made heavy use of 8-bit parts, and Motorola had application notes on interfacing other company's 8-bit devices as well as their own. You could mix 8-bit peripherals and 16-bit memory without stretching.

Motorola even had an app-note about interfacing the 68000 directly to 8-bit memory, but any decent engineer would have looked at the note and realized that the cost of 16-bit memory was not really enough to justify hobbling the 68000 to 8-bit memory.  That's one of the reasons the 68008 didn't come out until a couple of years later, and the primary reason that very few people used it. There was no good engineering reason for it.

Well, there was one meaningful cost of 16-bit wide memory: You couldn't really build your introductory entry-level model with 4 kB of RAM using just eight 4 kilobit dRAMs. (cough. MC-10.) You were forced to the next level up, 8 kB. 

IBM knew that the cost of RAM was coming down, and that they would be delivering relatively few with the base 16 kB RAM (16 kilobit by 8 wide) configuration. Starting at 32 kB (16 kilobit by 16) would hot have killed the product. Similarly, the cost of the 68000 would come down, and they knew that.

Management was scared of that.

Something you don't find easily on the Internet about the history of the IBM Instruments S9000 was when the project started. My recollection was that it started before the 5150. It was definitely not later. It had much more ambitious goals, and a much higher projected price tag, much more in line with IBM's minicomputer series. There was a reason for the time it took to develop and the price they sold it at. But even many of the sales force in the computer industry didn't understand the cost of software and other intangible development costs.

Consider how much damage the 5150 did to IBM's existing desktop and minicomputer lines. Word Processing? Word Perfect was one of the early killer apps for the 8088-based PC. Spreadsheet? Etc.

IBM management knew too well that if they sold the 5150 with a 68000 in it instead of the 8088, a lot of their minicomputer customers were going to be complaining to high heavens about the price difference. They knew the answer, but their experience showed them that the too many of the customers would not believe it.

That was the real reason. They hoped the 8088 would be limited enough to give them time to maintain control of the market disruption.

I think they were wrong. But it would have taken a level of foresight and vision that very few of management withing IBM had.(very few outside IBM, either.), to take the bull by the horns and drive the disruption.

"That was the real reason" - well, that could be, but without documentation to back it up, it's jus another claim without proof.