It should build under anything even vaguely POSIX-ish. (eg, Linux, BSD/OS, NetBSD, OpenBSD, Solaris...)
If nobody is listening to the CM11a, it saves up a few bytes worth of messages. As soon as any program starts listening to it, it dumps them to the computer all at once. This is actually a feature when you think about it.
The CM11a only has 8 bytes of memory for this, so the best you can hope for is 8 commands waiting for you. However, since most commands are two bytes long (eg, "Address A2", then "Turn A on"), this can be as low as 4 commands.
Yes. The X10 protocol doesn't actually have commands to turn a particular unit on. Instead it sends two commands, one to "address" the unit, and a second one which is a general "on" for that house code. Thus to turn on light a2, the controller sends "address A2", and then "house A on". Xtend emulates the X10 protocol in software, so it works the same way.
Performance-wise, letting Xtend talk directly to the serial port is better. (eg, "port /dev/ttyS0" or whatever). If you use it with the "File" option and heyu, incoming X10 commands will have to go through the heyu monitor, into the file, out of the file, and into Xtend.
The CM11a is trying to help you here. If it sees two dim or bright commands happening within a short duration of each other, it will translate that into one larger dim command. For example, if you send "dim 5%" twice, the CM11a will see that as "dim 10%". There is no way to tell it not to do this, so dims and brights are inherently less accurate than plain ons and offs.
It's a feature, not a bug. The program runs your command lines in the background as fast as possible. There is no guarantee which command line will get the processor first.
There are some implications that are not necessarily good if this is
allowed. For example, what would happen with a command that read
"a2 on heyu turn a2 on" ?