If you don't fully/correctly implement the APIs, it's your responsibility to tell folks what to avoid doing... or, better, to set it up so that if they try to do something you don't support they'll get a diagnostically useful error message. Again, see the SQL extension code for an example.
We do not guarantee that DOM2DTM _won't_ cache data. We just aren't doing so right now. That's a storage vs. performance issue, and is subject to reconsideration in the future. In the process of reimplementing DOM2DTM, you could make that an explicit design point in your code. But I really don't think that explicitly supporting alteration to the source DOM is a Good Thing. As we move toward optimizing the stylesheets, it's going to become harder to defend assumptions about order of execution.
