I'll comment a bit on thread-safeness.
It seems that libxml/libxslt are not thread safe. I'm not sure if ns_xml is also not thread safe. You can always make non-thread safe library to be thread-safe by wrapping all calls in mutexes (running into a possibility of slowing system down due to lock contention or deadlocks if you're not careful). There are some calls wrapped with mutexes in ns_xml, but not many. I guess only Curtis can tell at this point what are they protecting and how confident he is in thread-safeness of the code.
The nature of threading problems is such that it's almost impossible to infer problems by code inspection (especially if the code is largely unknown, as is libxml and ns_xml to me).
All you can do is to increase level of confidence by running stress tests. I've only run stress with ab (apache bench) that tries 1000 times 10 simulataneous connections to a page that does XSLT transformation of one XML doc. It seemed to work fine. Surely more elaborate tests can be done.
To summarize: there are no known threading problems in ns_xml. If you run into one that you think can be caused by ns_xml threading issues (I think it can show as either corrupted output or AOLServer crash) please let me know and I'll investigate. In that case a very detailed description of the problem, setup etc. will be needed.
I plan to use ns_xml in my own web services so if you find any issues send them to me, I'll actively maintain ns_xml. I'll fix any reported bugs that I can reproduce and re-release a new version. I might be less receptive to new feature requests due to time limitations (like, it would be nice to add SAX API but as long as I don't need it badly I won't work on it myself; if, on the other hand, someone sends me a patch to implement new functionality and the patch looks good, I'll add it).
