I'm afraid but I get the impression that you confuse some matters here ...
tread-safety vs. resource sharing in concurrency modes
my assumption was that the XoTCL Objects are thread safe within AOLserver.
XOTcl _as C extension_ is perfectly thread-safe in the sense of being deployed in thread-enabled tcl interpreters. What you refer to is the ability of sharing XOTcl objects as resources under concurrency, e.g. between several threads. And this is not possible, though this is more related to underlying Tcl than XOTcl. in the context of the tclthread extension, there is resource sharing under certain limitations (shared thread vars + shared channels, for instance). The issue here is that you cannot share commands and procs, as far as I know due to the current setup of 1-interpreter-per-thread. This also applies to XOTcl objects which certainly built upon the same low-level infrastructure as Tcl procs and commands. Currently, there is no BLACKBOARD kind of architecture in a scripted multi-threaded tcl applications realisable. Zoran, however, also discusses a BLACKBOARD-like architecture based on naviserver over at naviserver-devel (can't find the link right now).
Future Tcl will come with with another concurrency technique called coroutines that will allow concurrency programming based on a model that is not that strict in terms of resource sharing.
I hoped there was an easy way to share an object among all threads and all clusters and that an object
as far as i know, you experimented with streaming/ serialising objects into ns_cache (another thread-shared space), didn't you?