I'm a "why?" person myself, so it's not for me to be critical of that. And I'm quite certain that you meant well here. However, the reality of the situation is a) that it doesn't really matter why having the code visible makes a difference, b) that whether or not it makes sense that it works this way has no bearing on whether or not it actually works this way, and c) that when you question whether or not it works this way without an opposing experience to share, it's not only not helpful but it is in fact potentially detrimental. If someone were to be able to say "I was able to login without having the code visible," then that would be helpful, but anything else is just a distraction from the information I put out there to help people. But okay, I'm quite certain that's not your intent, and it's all good. We can move on.
So with that said, I'm with you in wanting to understand why it works as it does. Your thought process contains understandable logic: "if I'm getting the same code on multiple consecutive requests, that code must be the valid code throughout the process, even when it's not visible." But it could be the case--and, based on the evidence, I believe it is the case--that whether or not the code is visible is a key factor for Apple in determining whether or not to accept it. That is, it could be that Apple deems that a code that's not visible is not acceptable. And there is logic behind this: if someone accidentally displays the code and then clears it, then from a security standpoint you don't want that code to be accepted. So why don't they invalidate the code and generate another on the next request? I have no idea, it seems like they should in fact do it that way. But the fact that the code is not invalidated doesn't mean they couldn't be doing something else to basically short-circuit things when the code isn't visible.
