On SoloProgrammingXpWorkarounds, we mentioned that a potential way to stay on top of the code when you aren't frequently pairing is to watch all the changes that your team mates make to the code.
If you have a good versioning system, this should be easy to do.
Break this section up into the individual "pros" and "cons" that are addressed.
"Read all the code that others check in." is just bogus. What's the purpose? You're better to focus on the quality of your own code.
It doesn't matter which developer types the code from which keyboard -- if you need to understand the code, it's yours. See: CollectiveCodeOwnership.
No. You need to understand the interfaces, the modularization, the responsibilities of each module, and how your code interacts with others. Trying to understand ALL code in a project is a waste of time, and it's going against your XP principles DTSTCPW, YAGNI and you can add here. Doing it this way in a non-XP project can be seen as an AntiPattern. Does the project manager ask you to understand all the code? If he doesn't, then better focus on your task at hand.
If you do your tasks sooner than it is required and wait for others to catch up, then by all means you're free to do whatever pleases you, including trying to understand the whole code. I hope you're not part of 100.000s or more LOC project. You might want to try to understand the code of gcc as well, if you're using it, since it is part of the project. The whole Java runtime and libraries is also a good candidate (including the native C part of it).