So because I've got a few minutes and can't sleep again, a quick explanation as to why people have seen the results with the RJ11 that they've seen.
In a normal keyboard controller, you have two clock signals involved. One is generated by the host, and the other is generated by the keyboard controller for internal clocking functions.
The first thing you should notice when you disassemble a Wyse PCET keyboard (the 102 key for PC use with RJ11) is that the PCB does not in fact, contain any clocking crystal at all. None whatsoever. In what is both a brilliant and mind-boggling design decision, they elected to rely entirely on an external clock.
Now this alone, would generally be NBD because there's plenty of microcontrollers which can take external clock. They're designed for it, so on and so forth. Transmitting clock over the RJ11 is no big deal.
What I've found is two key logic blocks which have given the results we've seen before with attempts to adapt it. The clock rate goes straight to hell and off the spec at the keyboard, every time. Yet it conforms to AT Set 2 after the U57 when fed to the i8042. Secondly that these clock rates seem to have been completely unrelated to AT specification.
So gentlemen, here's the point folks better equipped than I can take over at again, and actually get this thing working. (Because seriously guys, these MX Blacks are the sex. ANYHOW.)
There's a trigger pattern expected from host clock to keyboard controller to set the correct PLL internally, most likely between 4 and 12MHz - using CPU clock as absolute with it's close link to RTC.
So when the thing seems too ridiculously fast? That's because the clock isn't primed correctly. They stapled on a rise-fall to trigger PLL internal to the keyboard uC.
We know for fact that the "U57" IC could not exceed 12MHz reasonably being locked through i8042 to CPU TDM. That means it would be i286 12MHz, 12MHz; i286 8MHz, 8MHz, and so on. You get the idea. But if the slope is too short, the controller gets the wrong signal and clocks too high.
Basically we need to know what comes out of the HOST looking for the keyboard more than what the keyboard can tell us. I don't have the tooling for that. However, I believe once we know this data, we can solve it pretty easily. The first trick is simply going to be capturing a 500ms window from power applied. The second trick is not frying everything trying to find that.
Get the handshake right, and all problems become solvable.