Change is handled in a very simple fashion in XP: implement in the easiest imaginable way and refactor in the future, if you need. One could rephrase this: take a requirement context (specifications) that includes everything that the software need to do today, and implement a piece of code that best matches those requirements. If the context changes, refactor the program.

I find this an oversimplification in some projects. I would like emphasise the interplay of different contexts, different measures of quality. For example: performance is rarely considered when the architechture of the application is designed. This was true for many web-applications in the beginning, but when it became clear how big slow RPC-calls were in distributed object systems (EJB), performance issues had an effect on the overall architechture. What was considered optimal wasn't it anymore from new and richer context.

By analysing the contexts which are existent for the application priceless information and insight could be gained. What I'm asking is that has someone refined these unmatured ideas? Has someone developed something, a methodology or a supporting product, that makes shifts between different contexts easier?

This issue is not overlooked by big players, MS for example with its EAI-solution BizTalk. BizTalk offers a technical solution for application integration, but doesn't provide a bridge over the different contexts in which the applications have been born. Integration servers are mere XML movers and transformers and lack theoretical ground to really make a new kind of application development possible. Do you agree?