Colin, What may be confusing you, is that the screenshots you have captured don't actually show the fault!
Measuring all the other ones that SiriusHardware had originally suggested, would have shown this, but they were a bit more involved to measure - requiring you to add extra pull-up resistors
However, what your screenshots do confirm is that the inputs to UC9 (74LS145) are all correct.
And we know that UC9's 10 outputs go straight to keyboard matrix's Row lines - with nothing else in the way, other than connectors
From your table of the responses you got from each key separately pressed, and looking at the layout of the keyboard, here:
http://www.6502.org/users/andre/peti...ards.html#scan
(I couldn't find a decent correct schematic for your keyboard at the time, but this was adequate)
Then it can be seen that the incorrect responses are all in the same (0..7) 'column' as the key actually pressed
- but are just one row higher from it. e.g. (Both in Column 0): Q is in Row-2 and W is in Row-3
So for a Q to actually be read as W, then it can be seen that can only occur if the Kernal is setting the PIA to UC9 4-bit BCD code outputs to 0010, to try to read Row 2 it doesn't get any response as key 'Q'
- So the (Row) Output 2 from UC9, isn't going Low
But when the Kernal increments the 4-bit BCD code (to 0011) move on to read the next Row (3), both Q and W keys give the same 'W' key result - So the (Row) Outputs 2 AND 3 from UC9, must BOTH be going Low. (And hence it must be faulty)
A simple short between Rows Outputs 2 & 3, would probably produce a Q and a W or ignored, depending on how the Kernal firmware works.
And the same fault happens between other row pairs, like (also column 0) 'Z' (Row 6) & 'X' (Row 7), both giving an 'X'
Hopefully that explains it (and is a bit more involved than it first seemed to me, but appears to be the best explanation for what is happening)