Very nice. I like the layering.
It would make it really easy to also add in support for using a shift register or a SPI interface:http://code.google.com/p/arduinoshiftreglcd/
While it has the same API functions, the interface isn't 100% backward compatible
so I do have some concerns about backward compatibility and coexistence with the
current LiquidCrystal library.
Since it isn't a drop in replacement for the LiquidCrystal library
(i.e. you can't simply remove the current LiquidCrystal library and replace it with this),
I'm wondering the value of using the same base name for the main header (LiquidCyrstal.h)
since using it will break existing code because the final constructor names are different.
Also by using the same name, this library cannot coexist with the current LiquidCrystal library.
So it is a full commitment to switching over that requires removing the current LiquidCrystal
library as well as modifying any existing code to use the new library.
What about using something like hd44780 instead of LiquidCrystal for the basename of everything?
That way the library is totally separate and insulated from the LiquidCrystal library and
can even coexist, which makes it easier for users to add without breaking any other
existing sketches they may have that currently use the LiquidCrystal library.
If the intent is to replace the LiquidCrystal library, then, IMHO, I think it is important
that it be a drop in replacement and still allow existing LiquidCrystal sketches
to continue to compile without having to make any changes, even if it is as simple
as updating the constructor names in the sketch.
I think it should be possible to provide 100% backward compatibility with the current LiquidCrystal library
by providing a LiquidCrystal.h header file that provides
the needed backward compatibility by including the other needed headers and providing the
needed mapping either through preprocessor macros or wrapper classes/functions to make
4bit mode work just like the LiquidCrystal library does today.
That way, the new library would be a true drop in replacement.
And while it would require the removal of the old LiquidCrystal library,
it would still allow existing unmodified LiquidCrystal sketches to continue to function, and new
applications could include the new headers and use the new constructor names.
One other small comment is that if the examples use .pde instead they would be easier
to use with the older IDEs.