We looked extensively into making it possible to create new bindings without restarting the server, and it turned out to be really hard. Basically, you have to make sure you create the magic internal proc in all interpreters, which is tricky. Not impossible, just tricky.

It was part of our efforts about a year ago to let you install packages without requiring a restart afterwards, but mimicking what happens during server startup when we're not during server startup anymore is just a tad complicated and error-prone.

So instead: Document it. Include a notice in the UI, and a link to restart the server right away ...

Why can't the file with the binding be added to the request processor reload list in the same way the APM adds a file that you've requested be reloaded?
That gets it into every thread's interpreter ...

Not quite every thread - since apm_load_any_changed_libraries is only called in the request processor, APM watches only work in connection threads (and not in scheduled procs, for example).

Hmmm... Although I guess ad_schedule_proc could be altered to prepend a apm_load_any_changed_libraries to any procs scheduled...

Of course the APM request processor reload list thing is still
recommended for development use, not production, right? It's always
seemed reliable when I've tried it but presumably the performance
overhead is significiant?

It's not yet 100% compatible with the usual way of initializing Tcl in
AOLserver, but
Zoran's recent ttrace
work should also provide a different and maybe better way of loading
Tcl code into a running AOLserver.

But, ugh, the current
ns_eval docs
(dating from early 2002) sure give a very misleading example of how
and why to use ns_eval. (Yes you can use it to "maintain global
variables", but you sure as heck shouldn't, that's what nsv is for.)
Unfortunately this newer
draft API doc
didn't update that part yet either.

ns_eval was broken in AOLserver 4 as of beta8 or so, I have no idea if it ever got fixed properly. I ripped out the one place we used it previously in OpenACS because of this uncertainty as to whether or not the old semantics would be re-implemented.