(Late reply, sorry.)
I have a question about sending scripts from one Bro to a second one, and
having the second one install the script at run-time, and I was wondering
how it would be done. Any help appreciated! Details below.
This requires a longer answer ...
We don't have any prepackaged functionality at the moment to simply
do a "send everything and install".
What we have are two things:
(a) a built-in function send_id() which will send a particular
script-level ID to the remote end, which will install it. That
includes variables but also event handlers, script functions,
etc. By sending all global IDs successively, one will eventually
have sent the whole configuration. (However, that would be best
done in C++ code by writing a new built-in function).
(b) If it doesn't need to be network communication, there's the
command-line option "--dump-config" that puts the whole
configuration into a binary file, which can then be picked up by
another instance dynamically (by copying the file into the
.state directory of the target Bro). Internally, dump-config
essentially does just what I sketched above in (a): iterating
through all IDs and serializing them.
So much for the theory. Now the practical part: I think this whole
set of functionality hasn't been used by anybody in a long time.
Because of Bro's internal structure, replacing policy scripts at
run-time is actually pretty tricky and I wouldn't want to bet much
money that when you try --dump-config, it will "just work". It did
seem to work well with tests done while implementing all this stuff,
yet I think it has never been exercised very much and the problems
are subtle here.
So, depending on what exactly you need, I'd suggest something
different, which is what the Bro cluster is doing:
(1) many policy changes are limited to fine-tuning, e.g., changing
the value of some configuration paramemter, like extending a
regexp to match more activity, or changing some detection
threshold. Sending just values of script variables works
actually pretty well and the Bro cluster limits online updates
to such cases: all variables which are declared as &redef can be
updated dynamically from remote. This is implemented by the
script aux/cluster/policy/send-config.bro in my branch.
(2) another typical policy change is enabling/disabling a certain
kind of analysis (such as now loading the HTTP analyzer, or
disabling scan detection). My branch has some code to enable
this from remote by grouping related events into "event groups"
and then allowing to enable/disable event groups remotely. So
this can also be done during run-time.
(3) finally, for everyting else (like adding new script code, or
changing an existing handler) Bro needs to be reinstarted. The
impact of that is mitigated by using persistent state so
that at least the most important state information is kept
across restarts.
Any questions? 
Robin