Why do you suppose the designers of the core, back in '78 or so, decided to make the chip capable of providing the baud clock to the serial port from T2? Clearly they intended it to be used for that purpose when T1 couldn't do it with the crystal selected for reasons other than the baud rate generator.

If you NEED a crystal frequency, for any reason, other than 11.0592 MHz or its multiples, why would you not use 'em if you can get an adequate baud rate clock from T2? If you NEED T2 for something else, and can't work with a crystal of a frequency convenient for T1 baud-rate generation, then you NEED a different MCU, one with more resources. When I've needed a timer, it's seldom been necessary to use a timer, though they are convenient if they're available. Firmware can handle timing as well as any timer. Clearly, there are times when a hardware is the only convenient way to do something, but, most of the time you can do without THAT one. Once in a while that's not the case. Most of the time, it is, at least from what I've seen since the first single chippers came out.

Now, you say,
"1)Show me a PC or a RS485/RS232 industrial sensor or an automobile, or a cellphone or a serial VFD that can communicate with mode 0. "

and I'd say, though I've never tried this, "hook up the audio codec input or output in something other than mode-0 with 11.0592 MHz and see what you get from a PC. Now, it'll be WAY oversampled, but you can make heads or tails from it, and even better, if you're operating at 12 MHz, because that will give you a precisely timed sample set based on a 1 microsecond interval which is easy to count out. Presumably you'd be processing the accumulated sample offline. Now with a one-clocker, which we both know and love, it would be quite straightforward to ship off the data to some other destination for later processing.

Then you say,

"2) show me how to communicate with a 9600 interface on e.g. a cellphone with a 12MHz crystal using a derivative without T2.
Communicate with a device that can handle a frequency deviation from 9600 or higher of more than 5% (a very generous amount, most can only handle ~3%)"

I'd say that, with a little effort, with 1 microsecond samples, you can do many of those things and stay within tolerance, since you're just sampling at 1 MHz on a 12 MHz 12-clocker. Yes, you could be off by a microsecond here and there, but that's not what Mode-0 is intended to do. Now, if you receive at 1 us, you'll know when you're going to be off by a microsecond by mid-bit, and a correction can be made in how you interpret the samples. Now, you can sample at a higher rate, and generate more samples, which has its own burden, but that will allow you to stay well within tolerance, say, at oscillator/4 and a 32.0 MHz oscillator. There are tricks you could use to compress the data on the fly, but it's not necessary if you can ship it out. Of course, that rate is WAY to high for the type of equipment you describe.

BTW, you've mentioned "extra" bits several times. What are they? The Mode-0 operation samples the data pin and left-shifts it into the shift register. When it's shifted eight bits, it moves it to the data register and generates an interrupt if you want one. Meanwhile, it continues to shift data into the shift register. Now, it only works in one direction at a time ... I don't see any extra bits there, however. There are no start or stop bits. It's in "shift-register-mode."

Now, why is it so important to preserve T2? T1 was all that the earlier i8048 had, and we all got by fine with it.

If you can do the above, I'll shut up.

Nobody wants you to shut up, Erik. I, for one, WANT to see what you say. It's just the tenacity with which you cling to some notions that troubles me. It's your place to advocate for your beliefs, however.

RE