It's great that I can log in to Google Mail, use their (ugly) tool there to manage my contacts, and the changes automatically get sync'd to my Android phone within a minute or so. It is less great that because I let Google know about my twitter account, it has a bunch of redundant contacts for the same people that I can't merge into their main contact. It is MUCH less great that if I use Google Chat through Pidgin, my buddy list has that 2-way sync with my contacts, as it is too easy to delete contacts (for organisational purposes) and need to re-enter things so my phone doesn't forget half its phone numbers.
Maybe this is a better reason to run one's own XMPP server and use it for chatting. I was doing this for awhile in the past (so my systems could programmatically notify me of things, e.g. "reply to a blog post") - it might be good to do it again.
The big moral of the story is that system policy is not always obvious, and choosing sensible defaults may be the only way to avoid confusing people with a daunting list of options but it easily can lead to gotchas (especially when people do things via APIs rather than UIs, as warnings can be slapped onto UIs). Yes, it makes sense to sync accounts between GMail and my phone, and yes it probably makes sense to sync accounts between GChat and GMail, but it's not obvious that deleting contacts will cascade over the system (although it might even be unreasonable for it not to, as it'd lead to an accumulation of crumbs or an unpleasant manual-sync task). There may be no coherent policy that does what the user would like (unless the user can say "I am deleting this contact purely to merge its information into another contact" - sure you could add a merge button on GMail, but not so much on the phone or on every possible XMPP client), so at some point we should either be involved in writing policy for our apps or at least informed of this stuff, probably. Or we might just keep getting occasional hard lessons where there really was no way to guess how the app designers might've done things. (One of the reasons I wrote a fair number of the applications I use daily, including this blog software (that syncs to LJ in case you read it there), is that I don't mind writing policy and I don't like policy surprises)
Email software (filters) have most involved policy-defining mechanism I can think of that end-users might use, so much so that with some of them we find "Easy", "Moderate", and "Advanced" modes for their preferences panels. I'm sure this stuff is irritating to program, and the permutations of options mean that coherent behaviour is harder to achieve (or prove). The other option would be to give people the ability to write greasemonkey-like scripts and let them go hog wild (maybe we should call this the Sendmail approach). It's not a great exclusive approach unless one can reasonably expect one's audience to have programming skills.
Today at work was spent mostly figuring out low-level Linux wireless access point software. Frustrating, but at least it's pretty much over with. If I can get the higher-level software to sit nicely on top of this, I'll have a very nice solution for a network of access points that share registrations.