This post contains a summary of which Thinkpads are affected and which aren't:
https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/Keyboard-firmware-scrambles-keys-on-all-T-series-X-series/td-p/4222626
There are two problems that some people will encounter here. The first is that when pressing "load" on some keyboards, nothing will appear at all. This is because of 2-key rollover and isn't the issue we are testing. The other issue is the timing issue, which is our main concern. So instead of using "load", try "asdf". This produces "fdsa" consistently on my machine and skips past the rollover issue.
I can also provide a solid guess to interpret the data's underlying cause. The scan rate for the entire keyboard is 125Hz, which is not good but is still a standard, acceptable result. However, the underlying behavior is from something else. All keyboards must have a debounce algorithm, because when a key is pressed, the signal switches from Off to On-Off-On-Off before settling at On. To prevent several On-Off signals from being sent because of a single keypress, the firmware must introduce some hysteresis. The "low speed" way is that once a key is switched, the firmware will wait until On appears several times before finally sending an On signal. This is very stable, but introduces delay. The "high performance" way is that the firmware will send the On immediately on the first switch, and will ignore any further switches for a short period after that initial switch. This is very fast and works perfectly as long as there are no spurious contacts, such as from conductive dirt entering the switch.
IBM's method is different from both of these debouncing algorithms, and is worse than both. It uses the "low speed" way for a single key. But when two keys are pressed, the debouncing is short circuited and both keys are sent. This is because once several keys are seen, the controller knows that the second keypress was not spurious, so it sends it a little sooner. However, this is also the origin of why the keys are scrambled. If you press "d" before "f", then under the "low speed" algorithm, you'd see df after a delay. But because of the short-circuiting, pressing "f" forces the "f" to be sent instantly before its delay is up, and it also takes precedence over the "d". This produces "fd".
We know that the A485 fixed this problem in BIOS 1.05, thanks to https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/Keyboard-firmware-scrambles-keys-on-all-T-series-X-series/m-p/4248893/highlight/true#M129058. If you have an A/E485 without the appropriate patch, please test it before updating, because we would like some data.
Lenovo inherited the bad debounce algorithm from IBM and uses it in the X/T-series. Lenovo's own algorithm, which is used in most E-series laptops and the A485 1.05 BIOS, works just fine.