No, the thread is very much alive still.
In practice it's not a big problem that it expects to receive a command as one read, but you're right, it is a shortcoming. Actually it wouldn't be that hard to fix it to wait for more data to arrieve incase of tcp/ip fragmentation during listing. I'm pretty sure the reason why there's problems with the LIST command is that some hardware vendors havn't bothered to implement the command, for me it's working just fine. Anyway, since the lirc plugin mostly works just fine improving it hasn't been that high on my to-do list.
Originally I just wanted it to receive the normal lirc commands, which are pretty short one-liners, and it just evolved from there. If I would write the Lirc plugin today I would take a different approach to it.
I have been meaning to rewrite the plugin using some other network library entirely. All I can say about asyncore (and asynchat) is to advise to stay away from it if at all possible. It has some issues that I ran into while working with the Lirc plugin. For example it does not update the connected state until some data is sent or received over the tcp/ip connection. The problems I ran into were in the asyncore itself, so not something I would attempt fixing.
Generally speaking people are holding twisted in high regard around the net so that's what I've been meaning to look into..
I'm convinced though that the next step is to redo it entirely with something better than asyncore/asynchat, so this is something I wish and recommend you to look into as well. If you want to continue development of the plugin feel free to improve upon it. If not then I will probably redo it myself sooner or later.
PS. I couldn't get your plugin to connect.. it dumps my eg log full of "Waiting for Chat.Connected" and then some exception.