I like the tohoughts, BUT.
Firstly, mention is made of TDD (which I assume means Test-Driven Development; if it doesn't, ignore the next couple of sentences and read on; sort of Agile really!) in the 'same breath' as XP, DSDM and Scrum. TDD is NOT a method or framework or a methodology; it is 'just' a technique (albeit an extremely important one).

So to Agile Frameworks. What do we actually mean by 'framework'? In physical terms it is a 'skeleton' that we 'cover in something'; that something may be different using the same framework ie a timber-framed house could be covered by more timber or brick to make the outside walls and plasterboard or plywood for the inner walls. Similarly we may produce a wire framework in a recognisable shape to grow a bush around and 'train' to the shape (topiary).
But what does framework mean in terms of software development? Is the waterfall 'process' of create Requirements Spec then create Functional Spec then create Design Spec then create Source Code then Test really just a framework that we hang the different detail of these 'documents' on?
Or is the framework a toolbox of techniques that we pick and choose from depending on the project needs?
I think that it would be v difficult to map Agile to Waterfall and come up with anything meaningful
I use and teach a 'generic' Agile lifecycle applicable at all levels of timeboxing that applies to DSDM, Scrum, XP, Lean and FDD along with a toolbox of techniques drawn from all the 'named' 'methods' (which I consider to be frameworks not methods); my generic lifecycle/toolbox also includes governance aspects (something that all ut DSDM ignore!).
I have pondered the idea of 'publishing' these ideas but I think that even if it was taken on, some groups would do it the XP way, some the DSDM way and it could be used in a waterfall way; there would then emerge different 'flavours' of the Framework which someone would name and we would probably be back where we are!
I think the main problem facing Agile at he moment is the 'richness' of the vocabulary; using the same word to mean different things and different words to mean the same thing ie Increment, Iteration and Sprint all mean 'the time during which high-level requirements are developed into working software'. A move to a common vocabulary would be a good first start toward common understanding

I think an agile process framework would be great and I would be happy to contribute to developing it if there isn't one. IF there is one please point me to it!

I suggest one of the keys to success is an agile process tailoring process. So that the agile framework can be used as is or tailored for needs.

Bob, I think one way you could achieve your goal of establishing a consolidated framework might be by defining "discovery paths" through the available Agile content suich as TDD, DSDM, XP.
Each practitioner will approach the learning curve based on relating new information to what they already know. So, a framework that starts with "choose your current discpline", and then "choose your current methodology and toolset(s)" can lead the reader through a series of comparison exercises based on the (standard) activites and tasks they already perform and how they are differnet in a given Agile methodology.
You know what I mean... statements like "today when want to accomplish "X" you do "Y"; if you were using XP, instead you would do "Z". Now, it's an oversimplificaiton, because there is no 1-to-1 mapping. But it is a way to gain perspective on the differences.
At a higher level, maybe you could use a similar context-oriented approach by identifying the "goals - stragey - tactics" inherent in the way the established standards address the concerns of software production and usage, and for each, provide a comparison to how a given agile methodology will identify the "goasl - strategies - tactics". For example, to address the requiremetn compliance concer, a traditional approach will use a tracability matrix. But an Agile approach will use a story with prioritized features.
I know what you mean about the struggle... The Cobit, ITIL, IEEE, ISO, make things seem so clear; But I would have to say that the lifecycle model itself is now a bit dated; IMHO systems are viewed in Agile more as organic entities with a very long lifecycle rather than phased, closed-end products.
Fundamentally it's a problem of comfort zones... People I have worked with who are trained in the structured methodologies just cannot mentally accept that not all requirements will be defined before the work starts, or that defining some elements of the architecture will be deferred to later iterations. Again, one relly has to go through a project to understand how these things are "finessed".
Personally, I have found that the Sashimi model is the most effective transitional methodology for helping people bridge that gap and gain some confidence that there really is a methodology there, not just "wishful thinking"!
I'll be interested to see what you come up with. I know there are some of these structured Agile Frameworks out there, but unfortunately it seems like many of them are minor adaptations to the tradiotinal SDLC rather than frameworks in their own right.

Rob, please consider that "Agile" (slippery a term as it is) is fundamentally an attempt to liberate human problem-solving creativity from the constraints implicit in a structured process methodology which, of necessity, will isolate the concerns of distinct disciplines.
The fundamental flaw is this: Advancements in software development tooling will always compress the disciplines closer together. For example, consider unit testing frameworks, or "FIT". The antecedent, non-integrated processes, activities, and tasks are of course still relevent. This history and it's accumulated expertise informs the creational act of establishing tests and tests frameworks. This is "Moore's law" applied to I.T.: value will always beincreased by integrating manual practices and skills into tools which automate such activities and tasks.

The ultimate evolution of software tooling will be for one well-informed person who understands the system objective and requirements to perform actions using tools that will simultaneously instantiate test cases, code, deployment, and verification mechanisms.

All that is to say, that any attempt to reconcile traditional and agile methodologies in a documentation format will have very short-lived value, because the clever folks writing tools will always be one step ahead of the analysts observing the evolving use of tools and practices.

I'm not saying the exercise has no value - as you point out, communicating meaningfully between groups that speak different "method lanugages" is essential to maintain a coherent industry. My point is that this communicaiton is more of a practial matter of "seeing and doing" to gain understanding. An analyst translating method terminology into verbiage, and then the act of a reader interpreting a document loses so much of the essential nature of the practices that it's a very difficult task indeed.

Changing the way one thinks requires that one change the actions one performs... I'ts like Montessori... you have to invoke "cell-memory" to transform the individual's perspective and cultivate deep knowledge.

I guess I;m suggesting more of a workshop format than a document.