I took a quick look at it. I'm not sure if VX can use threads properly, but unless it uses Ruby 1.9.x, it can't. The threads are not real threads and hence one shouldn't bother with synchronization since everything is running sequentially anyway. He might as well use a normal sequential code. The other main reason why I didn't do it is because WinAPI calls are always blocking. They can't be non-blocking. And even if you use virtual-threaded Ruby code, it will freeze in the whole application when it comes across an API call.
I am going to make the data exchange system a bit better and more generic so it's easier to add additional data. I'm having in mind the same subsystem that I used in the Blizz-ABS Controller. The interest algorithms for data exchange he is mentioning can heavily improve performance. Currently the only actual interest areas are maps. But that can be changed. It will increase server load, but it should decrease network load.
As for the rest, by all means, if he can reuse more RMX-OS code, he should. I tried to design specific aspects generically so the very core of RMX-OS can be easily transferred onto VX (pretty much the Network class and everything inside module RMXOS).
He's got a lot figured out already after all. Even why I used tab characters as parameter delimiters in the network communication protocol. xD
An interesting remark I have noticed is the socket code coming from Ruby 1.8.1. Honestly, that's the same way I found it. I couldn't find the original in Ruby 1.8.1 either. O_o
EDIT: Yay, I posted a comment. xD As soon as the moderation staff approves of the comment, you should be able to see it.