Hi liudr,
as I thought, you've built a protocol on top of the LCD library. So to control several LCDs using a serial line, you most likely have a daisy chain with a small controller on each node.
Now the whole thing about the LCD library, is as follows:
The LCD library is a pure abstract class that implements the generic mechanisms to control a Hitachi HD44780 controller. This means that it implements sending the actual commands to the LCD that it understands. For example, the base class implements:
void LCD::blink()
{
_displaycontrol |= LCD_BLINKON;
command(LCD_DISPLAYCONTROL | _displaycontrol);
}
Regardless as to how the LCD is driven.
Now, each base class implements the initialization details and access mechanisms to actually write to the LCD.
In the example above, the command in every implementation, ends up calling the send. This send is in fact dependent on how you write to each LCD (4bit, 8bit, I2C, SPI or SR).
Therefore, this is not compatible with the way you send commands to the LCD, since there is someone doing these operations on each node. A different story would be if you sent to the LCD commands like: <bot><address><command>\0x80<eot>. This command would arrive to node with address <address> and write to the LCD a command of value 0x80. This would cause the cursor to position at location (0,0). You would then have to send <bot><address><data>Hello world<eot>, and would write the message.
So, what this library would understand is the <command|data><values>. To do this in the library is straight forward. However, on top of the library you have built a small link protocol, i.e. <bot><address><my message><eot>.
Not too sure if I have explained my self 
.
So as a conclusion we could say that the library could be extended to process messages like: <command|data><values>, where commands are binary commands sent to the LCD and data is whatever you want to write on the LCD via a serial link, for example. Could you have a link protocol on top within the LCD library? Yes you could. In the sense that, you could have a class called "LiquidCrystal_SerialAddr. This could send LCD messages to the other end in the following format: <bot><address><my message><eot>, where <my message> ::= <command|data><value list>, where the value list for commands are the raw control commands for the LCD. The LCD driver would just need to have in the constructor the address of a remote node.
The only problem here is that you have to build on the receiving end a small "serial to LCD proxy". On the serial to LCD proxy you would have to have an intelligent processor that would initialize the local LCD, and then read from the serial line, interpret the header, determine if its a command for this LCD, and call the send methods of the LCD accordingly. Broadcast messages, could have 0xff, how would they work: what ever comes over the serial line, I write it to the local LCD and resend it over the other serial line of the daisy chain.
What do you think? Is this in the lines of what you were thinking?
See my signature.
). So what characters, besides 0x80 are considered as commands? I know that sparkfun serLCD uses 254, or 0xFE, to start a command, right?