The existing adapters show the required API -- anything public in them is part of the API. They were developed internally and are not part of the Ext public API, and so were not doc'd. For the one or two people that might potentially want to build a new adapter, that does not merit the effort -- plus, anyone with the skillz to write an adapter probably won't need much help from us...
My understanding is that the adapters were intended to allow interoperability in environments that already had other frameworks. In some cases, it is hard to justify to management the cost and risk required to rip out an existing framework in order to use some of the outstanding features of another. In my case, I've come into a development organization that had already standardized usage of the mootools libraries. While this provides a lot of great low-level functionality, there's not much in the way of UI components.
I've seen other seemingly-defunct threads in this forum regarding a mootools adapter, so it seems more than one person has had interest in such. I haven't had time to reverse-engineer the existing (compressed) adapter code and am certainly not adverse or afraid of writing one of my own, but doing so without any API domain knowledge or support might require more time than I have. If someone has a suggestion on how I can leverage the Ext without such an adapter and without stepping on mootools, I'd appreciate hearing any ideas.
It's not so much a matter of "stepping on" mootools, just that there will be some redundant functionality that you won't use by including both moo and Ext base. It's not really a problem, just extra bytes.
The adapters are available in the download uncompressed in src\adapter.
Cool. I appreciate the quick response and insight. I will take a look at the actual adapter source (which I somehow overlooked) and do some simple prototyping within our development codebase to see if I can get away without an adapter as you suggested.