If we are ever to replace the book and taxonomy modules in core with something more powerful, then there absolutely MUST be an upgrade path. If a new relationships API isn't able to achieve that, then it's simply not practical. Sorry to sound so negative about it, but building such an upgrade path is a task for which I personally don't see the light at the end of the tunnel.
Whenever there is talk of something as fundamental as changing Taxonomy, the benefits need to be overwhelming to justify the changes. Category.module's solution is good *given the presupposition that Taxonomy as it exists will remain in core*. It's remarkable in that it requires no core patches -- a testament to both the clean design of core at the moment and your skills in writing and maintaining the wrapper. The suggestion at the beginning of this thread, however, was that Taxonomy itself be revisited and rebuilt with greater flexibility. I agree wholeheartedly that an upgrade path is an absolute must. If we're talking about a rewrite, though, all we need to do is provide an upgrade *path* -- not a mirror of the current module's data structures. Dman's relationships module, for example, is a conceptual superset of both book and taxonomy. The data for both modules can be expressed in relationship.module, and taxonomy/book wrapper functions could in theory be provided to expose those relationship types in backward-compatible ways. I'm not suggesting it as an 'alternative' to taxonomy, just an example of the sort of next-generation system that would add more value. To summarize, I think that providing an underlying API for general relationships -- which taxonomy and book would both be upgraded to utilize -- would provide more long-term benefits for Drupal than layering more and more functionality (and compatability wrappers) on top of what is essentially the same system. Yes, it takes work. Yes, it would be a difficult conversion. No, it is not impossible -- no more than formsapi was. That was a pain and a half (still is in some ways) but it is a similar leap in terms of core flexibility and functionality. In this case, we also have the advantage that most modules don't concern themselves directly with taxonomy -- taxonomy.module does the heavy lifting via nodeapi. --Jeff