As I understand, you connect your Arduino to two different target machines and on one it works and on the other it doesn't.
So it seems there is a difference between the initialization requirements of the two machines. On this page at the very bottom there is a listing of a possible initialization sequence. Start by comparing your initialization to that one.
It will be a lot easier by using a logic analyzer. I am using the Intronix Logicport, but there are both cheaper and better ones, though not at the same time.
Tapping into an open-collector bus is a bit cumbersome because you don't see which device is talking. However, if you put in a series resistor at the end where the pullup is not, you can tell by the voltage level which device is holding down the bus. Every open-collector bus (like PS/2) needs pullup resistors, usually they are built in in the PC.
You can see the different voltage levels easily on a DSO. With only a LA you have to record twice with different threshold voltages.
First, I'd say dump the wireless requirement, at least for the early prototypes. Once you have a prototype that works, and you've picked up some electrical knowledge along the way, you can add-in wireless after-the-fact. Assuming you've designed the firmware well, it should be fairly easiy.
Then, I would say the approach I would recommend would be to target a microcontroller that can easily emulate a HID device.
The cheap and easy approach, and the one I would take, is to buy an arduino leonardo. The leonardo (and the makey makey, for that matter), both use an ATmega32U4, which is a microcontroller with an integrated USB interface.
Since the USB interface is part of the microcontroller, rather then a separate, purpose-specific device, it can be configured to act as a arbitrary HID (human interface device). In fact, there already exists a library for using a ATmega32U4 as a USB keyboard.
Now, lastly, you are basically almost certainly going to have to use a switch-matrix of some sort. Aside from designing your own circuit-board, with an enormous IC (such as a 144 pin TQFP, or similar), you are not going to have enough IO lines to have a dedicated input for every key.
This is fine. Switch matrices are a well-understood practice, and if you're really concerned about button aliasing, you can add a diode for every switch, and make the circuit-board incapable of aliasing.
For the moment, I would suggest you buy an arduino leonardo, and throw together a prototype. I think you're underestimating the mechanical complexity of this build significantly, and having the electronics you need to at least get the system talking to the computer, and acting as a keyboard will let you start poking around at the mechanics.
Best Answer
I don't know what year those came out, but I think your picture tells me it must have been after 1980. I actually modified an IBM Electronic Model 85, which probably competed with your unit at the time, in order to use it as a printer for my computer. I did all the work needed to figure out the communications used between the keyboard and the control circuits (it used reed relays at each key), designed the hardware, wrote all the software, and it worked the very first time I tried it! My unit was purchased new, I think, in 1981 or so.
If this is a similar unit, then the answer is yes, you can do this. It's just a matter of collecting detailed information about the keyboard. You show a ribbon connector, which is fine. But you need to characterize the exact details that travel on those conductors. I used an oscilloscope. You may need to use a similar tool, as well. Some of the lines were used in combinations. There was almost no pattern, per se, too. So I just created a table of observations and made sure that the software replicated these. And it worked.
But I think that with sufficient details, it's quite possible.
In my case, I was able to keep the typewriter functioning as a valid typewriter AND use it as a printer via a serial port interface. I just kept my hands off of the keyboard when printing.