I'm wondering if muti-bots (bots that use one main bot and multiple "slave" bots to do messaging) could be handled better.

What we've done on Campalot is create a core module for the main bot that has the functionality for ordering the other bots around. For example, when an alert is sent out instead of having the main bot send out the message, the main bot sends a command (via tell) to the other bots who then start ending alert messages.

It works, but it's somewhat hackish and lacks flexibility.

Alternatives include writing to a database table, but then each bot has to constant query the database. Not exactly ideal.

What other options could be used for communicating between bots that are running under the same server?

Is there some trickery that could be used to run StartBot.php and have all the bots start up and be managed under one controlling process?

Other ideas? What I'd like to be able to do for example is have a mass alert go out and then allow users to reply to that tell to join the main bot. Again we could fall back to tells or spam at a private group, but I'm still wondering if there are better/other options...

The best way to handle multi-bots like you describe them would be to have a single script "spawn" multiple connections to the chatserver instead of just one. All incoming messages would then be handled in the same "handling object" of the same bot. They would no longer have only a single "channel/group/player" name/ID as origin, but also the connection that received them.
In this design it would be trivially easy to receive a command with "bot A" and act on it with "bot B". Mass message spamming and buddy lists over 1k people also become very simple to implement. There is no longer the need for an extra "communication layer" between the sepearate bots.

I doubt that it would be practical to "rewrite" BeBot to support this though. The very essence of what makes the bot "tick" needs to be changed significantly.
AOChat.php cannot be used for this (the sockets communication implementation is too naive) but you can keep the AOChatPacket class and copy&paste the crypto stuff.

The tricky part is to come up with a good sockets implementation that stays fully responsive, no matter how many sockets are actually used. It should be low on CPU load when it is just "waiting". It should also allow for flexible cron jobs. The PHP function socket_select can monitor any number of sockets and it can also be given a timeout.
One possible implementation looks like this:

1.) Go through list of cronjobs, execute those that have expired (and maybe restart them).
1a.) While doing that, also find the one cronjob that expires next and remember the time until it does.
2.) If we have a next cronjob expire time, calculate sec and usec part out of it which is given to socket_select as a timeout.
3.) Put all listening sockets and sockets that wait for data into the read array.
4.) Put all those sockets that have data in their objects write queue into the write array.
5.) Give read/write arrays and timeout to socket_select. Now socket_select is in control of the script. It will return control once the timeout expired (to execute a cronjob) or until a socket is ready to read/write.
6.) Write to all sockets that socket_select reported as "ready to write"
7.) Read from all sockets that socket_select reported as "ready to read" (and maybe act on it)
8.) Start over at 1

This implementation allows any number of chatserver connections (until Funcom starts to block your IP because you have too many). Downloading a XML file or any other data will be done in the same loop (reading and writing would be done by a "FileDownload" socket object and not the "BotCore" socket object in that case).
The cron jobs are _very_ flexible. You can choose any interval you want, from 1ms to many hours. They are not super accurate though. They will always expire a little later than you want but the error will be very small (< 100ms).
While socket_select is in control and waiting for a socket event, CPU load is minimal.

If people are interessted I could post a script snippet from my bots "master loop" that does what I described above. With some explanations that would be another "wall of text", so I didn't add it this time.

---

If you must work with multiple bot scripts (a few BeBots) then using ingame tells to communicate between them is probably the easiest solution. Personally I would prefer to use a local sockets connection between the two (or more) scripts because sending a command over the internet to FC and then back to the very same computer where it came from doesn't make much sense to me... but implementing that is probably as much work as rewriting the bot core to support multiple connections...