My original plan for implementation would have followed three large patches with errata in various other patches. The nsIAbCard is relatively self-contained and atomic, so that was how I came up with the plan. However, the startling results from attempting to do nsIAbDirectory refactoring makes this idea unfeasible.
My goal was to remove as much of nsIAbMDBDirectory as possible, which would require invalidating nsIAddrDatabase. That requires major changes to import and palmsync code. Throw in the difficulty of going from a file to an address book directory or a database to a directory and you get some hair-raising complexity. Then add in the fact that mailing lists are, well, black magic, and this process becomes especially complex. And large: my latest WIP touches some 68 files with a diff of a mere -693/+836.
What causes the sheer magnitude of difference in complexity? A card is quite lightweight: it is essentially a map of properties with a bit of extra stuff. There is therefore only one implementation of a card with five sub-implementations that refine it somewhat. A directory is the opposite: a heavyweight object with 4-6 (depending on how you count them) different implementations, sharing little meat among them. A mailing list is quite like black magic: they pop into existence when you need them, and creating one requires some non-intuitive steps.
So, what's my new plan? Well, lesson #1 is to stave off nsIAddrDatabase-gutting until after mailing lists are done. The next steps will be more atomic: the creation of nsIAbCollection and the involved refactoring come is first (probably split up into two or three patches), followed by mailing list sanity with nsIAbGroup (again, maybe a few patches itself). Only afterwards will I remove nsIAddrDatabase from import and palmsync (probably in two batches). Trivial removal of nsIAbMDBDirectory (i.e., where it is used for cardForEmail) will probably be in one of the first directory patches.
Of course, some of the more ambitious changes will need tests, but it looks like hwaara is being nice and writing tests for import (see bug 421050).