"the issue here is that any '51 input that float (in your case no key) will be high, thus you can not see "which one restores the row to a high""
But I CAN see which one restores it to a high, because my fat finger is still connecting the column (which is low) to the row (thus making the row low) when my code tells the columns to go high in turn. After column is set high, it checks P1 (which contains all the inputs). If P1 matches the snapshot I took when the row initially went low, then we know that setting this particular column high had no effect, and try the next column. When it finally gets to the right column, the row which was pulled low when I pressed (and am still pressing, because this is obviously happening pretty quick here) will be restored to a high, because the column I'm still connecting it to just went high. This time when checking P1 we see that all rows are high, and we know that I'm still pressing a button, therefore we know we've found the right column.
This is all working when outputs (columns) are Push-Pull.
Decoding breaks down when I make the columns open-drain. From reading your post about speed though, and doing some additional reading, I think this may be due to the rise time of the pullup.
I think I see how your slightly different column scanning method may offer some advantages. I think some experimentation is in order.
I really appreciate your taking the time to help me with this. I'm learning a lot.