One of the root causes of this problem is that managers and customers don't really understand software.
XP intends to be a means to break this language barrier. Snapshot releases are made every week or two, so the customer can see the progress being made and general direction being taken by the project. This helps insulate the programmer from the instability around her.
A better solution, proposed by Cooper in the Beck-Cooper interview, would perhaps be to introduce a middleman who speaks both the language of the customer and the language of the developers. He would act as a translator, so that instead of needing the iterative process of releases to achieve a design the customer can be happy with, the customer and designer would agree on a design expressed in the customer's language, and that design would then be presented to the developers for implementation.
This would result in a better expression of the customer's ideas. The result is that the requirements don't change in mid-stream. In addition, since the infrastructure has been designed already, it is no longer necessary to repeatedly recode a particular functionality, which is unfair to the developers who coded it the first time and unfair to the developers who recode it.
However, the point of a software engineering methodology should not be blame-transfer. An ideal software engineering methodology should be the one resulting in the most functional, least-buggy, most efficient code, not the one which results in least inconvenience or hassle for the developers. While there may be overlap, there will always be a trade-off.
Pair programming assumes that both developers are on the same page. If this is not the case, then the benefits are for the most part lost. In the one case, the programmer not typing is on the ball, that programmer will find herself dictating to the programmer at the keyboard. In the other case, the programmer typing is the one on the ball; either she is typing without explanation, in which case the other programmer is getting progressively more lost, or she is explaining as she is typing, in which case she is losing ground.
One of the requirements of continuous integration is that the integrated code always runs. This process assumes that once a core component is integrated, it won't change significantly. This resists changing any such component, even if the redesign is essential. The interaction between continuous integration and refactoring, which is supposed to alleviate this problem, is presumably left as an exercise to the coder. It seems like the result would be a game of catch-up.