Yep, apparently I got that wrong. I haven’t written a serial driver so I guess I assumed these UARTs had a mode where the handshaking worked in automatic mode.
But, as has been noted, if you have an interrupt driven serial port you can handle this handshaking despite CP/M’s polling based tty model, and at least some CP/M machines *did* do this… and even explicitly enabled implemented type-ahead buffers, so... whatever. If you want to keep obsessing over one tiny point it’s okay, I’ll yield and agree that keyboard buffering probably wasn’t common on computers that cost less than, I dunno, $5000 or so?, in the late 1970’s.
UARTs since the 16c550 are usually capable of supporting automatic flow control, and some older UARTS were also capable of this, and it's something I've implemented on logic-built uarts prior and I got that idea from elsewhere at the time in the 80s.
A bigger issue for early uarts (and even some modern ones ) is whether they are double-buffered - that is, can you receive a character in part before the current character is polled by the CPU.
Otherwise, once the next start bit comes along, your data disappears or becomes corrupted, so you have to receive under direct interrupt rather than polled mode.
There was a big move to get 16c450 uarts in the early 90s when Windows apps started to work with Modems and then everyone wanted 550s. The last uart I was working with was the 16c750 which has IIRC 64 byte buffers and autoflow.
My recollection was that keyboard buffering wasn't something generally required on low-end computers in the 80s because people didn't really type on them too fast, and generally you only pressed a key when the running program was already waiting for you.
Users were trained by the software of the era, and the software of the era was pretty big on "Press a key" type prompts to let you know it was time to press a key. Complete with jokes about the any key.
I never heard of a terminal that inserts a break into the buffer at the start rather than the end though. That was something I was unaware of. I never saw anything that buffered the keyboard before the PC came along with it's own computer in the keyboard.
CP/M wasn’t the problem. Not even a little.
Inability to run CP/M was definitely a negative consideration in such machines - at least in Australia and the UK. Prior to widespread recognition of the PC to set the direction of all future computing, CP/M and even S100 were common themes that people wanted and asked for. Wordstar was still the defacto standard. So at the very least, I'd say "A Little Bit" even if I don't know how much.
Inability to run the same software on multiple platforms was a common negative theme. Often you got a platform specific version, and yes, I know many CP/M versions were *specifically* for that version and the average user wasn not going to tweak their copy of wordstar, but the widespread beliefs amongst those who didn't use CP/M was that it would allow you to use all of the software written for CP/M for almost any machine.
Incorrect assumptions like that were pretty common in the early and mid 80s.
This is why even more modern UARTS with FIFOs generally interrupt at a high water mark a few characters below the receive FIFO being full. The 16550A, for example, has a 16 byte FIFO, but lets you set the receive interrupt to happen at 1, 4, 8 or 14 characters.
And it supported autoflow ( automatic assertion and checking of CTS/RTS ) so could be used between two systems in polled mode without interrupts enabled.
By the time the 550 came out, the needs of a multitasking OS and lack of interrupt support for many apps changed everything.
But the early interrupt was because the timeslices were pretty slow and there wasn't always control over the transmitting side anyway. Serial interrupts could be masked by other activities also - just because there's an interrupt pending doesn't mean the computer is going to respond right away under all circumstances... Especially if there's disk activity going on.