I've just run into a bug in Empathy, whose root cause is that TpProxy emits 'invalidated' when it's being disposed. The bug is as follows:

* EmpathyTpContactList keeps a ref to each of a connection's Group channels in a hash table.
* When a Group channel is invalidated, it cleans up, and removes them from the hash table (unreffing them).

So far, so good. Now:

* If a new Group channel appears with the same name as an existing one (this could be argued to be the real bug in Empathy: I think this happened because the old Idle connection didn't die before Empathy tried to reconnect, so the old Group channel proxies were still hanging around), it replaces the old channel in the hash table.
* Replacing the old group unrefs it.
* The old group's refcount hits zero, so it's disposed, and emits Invalidated (raising its refcount temporarily to 1).
* Empathy's invalidated callback fires, and removes the group from the the hash table, unreffing it (a second time!).
* The refcount hits zero again, but TpChannel's dispose() is not idempotent so everyone dies (patch to follow).

I don't think that TpProxies should emit 'invalidated' when they're disposed. If you care about a proxy's validity, you should own a ref to it. Conflating an object's spiritual lifecycle (whether it's 'valid') with its C lifecycle seems to be the root of a number of bugs (see also: the conflation in CMs between channels being unreffed and emitting Closed, leading to hacks to break loops: #20946). We can't change this without breaking the TpProxy API, sadly.