3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking "but that would be a step backwards!". Yes, I think so.;-)
Would it? I can tell you this- the pacman 2.9.8 codebase was about half the size of the current monster, and we have a lot of crazy design issues going on. Instead of trying to write a pacman library, why not just implement a friendly frontend, command-line interface, which is a bit more Unix-y? For example, monotone has its "automate" command (I haven't looked at this in some time, so let me know if I am wrong) that is designed to be used by other clients as machine-parseable. git is based around this concept as well- look at all the low level tools like rev-parse, etc. Well, I don't think we can easily compare the current codebase with 2.9.8. There were _dozens_ of bugs in 2.9.8, after 3.1.3 release we got no "real" bugreport in FR. I think library is better than some server<->client stuff, because now we can easily share internal things with the front-end (for example: pkgcache) without interchanging tons of data. So my vote: keep libalpm library.
Bye