It is still a good idea, although one has to differentiate between "run a command in all threads" vs. "update the blueprint". If the intention is to update e.g. a variable in a tcl-namespace, the first one can be very lightweight, while in cases, where the blueprint is large updating it can be quite costly (since after invalidation of the blueprint of a thread, the whole blueprint has to be re-evaluated (takes in openacs.org 0.7 secs, will be worse on e.g. dotlrn installations), which might lead to "random", unexpected delays. Furthermore, just using ns_eval will not be sufficient, if we want to keep features like e.g. "watching" of files, etc.
There is a small machinery [1] which resolves the issue of the e.g. updating schedule threads by allowing to send commands to other threads in a more generic way than in the request processor. This approach updates the after-request callbacks to issue update commands in cleanup steps. Therefore it affects all threads as long these call the cleanup callbacks (which is a good idea as well to cleanup e.g. ns_sets, etc.) This requires some work. The functionality can be made independent from xoctl-core and can be added to the core.
I think, we should add a "refresh blueprint reform" the to the wish-list of the release after 5.9.1.
[1] https://openacs.net/xotcl/show-object?object=%3a%3axo%3a%3abroadcast&show_source=1&show_variables=1&show_methods=2
