Sorry for the lag... I've been out of town for a few days.
I haven't written an address book replacement as things have just been too hectic here, but the implementation of addresses, geographic locations and contact info that I described briefly in this post are complete and pretty well-tested. For the Berklee project, I've integrated the ability to keep a reference to a contact info object directly into parties. Also, persons or subtypes thereof automatically instantiate a contact info object for themselves upon creation.
A nice feature of the system is "swappable" address widgets, that will reload the form that the user is working with to display a different address widget depending upon the country that they select from the dropdown list at the top. This required changes to the templating system's form generator (none that break backward compatability) to create an explicit is_invalid state because we used to use ![form is_valid form_name] to display an error banner at the top of forms asking the user to correct the errors contained in the form below, and clearly is_valid is used to imply that the form is complete and ready to be acted upon by the application, so changing the semantics of is_valid (by adding an is_valid_and_ready_to_go state) seemed ludicrous.
The one problem with the swappable widget is that it (of course) requires javascript on the part of the client (albeit very simple and cross-browser compatable), and I wasn't sure how palatable such a concept would be to the community here. Though I haven't played with them recently in my code base (because our site requires them), non-swappable widgets have always been an alternative, and any developer with an aversion to the JS widgets could stick to just using the static versions (though defaulting the country in a useful way becomes nearly impossible unless you ask them what country they live in prior to displaying the widget).
Anyway, I'd really like to help get this into the core, as we've found it to be easy to code with, and it provides clean ways to do radius searching against all sorts of geographic data. The address system at least requires a number of acs-reference packages, and as such is a little unwieldy on the install -- not too bad, mind you, but I can see people without a need to use contact info not wanting to put up with the hassle. I suppose it could be cut along the line between contact-info and addresses... Contact info has no external reqs to speak of as it is just a holder for telephone numbers, etc, and keeps a reference handy to an address object. Contact info could be core and addresses an aftermarket option, and you'd still get a lot of advantages (like not needing to do DDL upgrades and overloading plpgsql functions on the core data model to install contact info after the fact).
Oh yeah... did i mention it's still PG-only? :) Shouldn't be too painful to port, though.
