From bug #27872:

Sjoerd suggested on the way back from UDS
that for as long as there are HandledChannels, telepathy-glib should ensure
that there is a Client "head" with an empty list of HandlerChannelFilters - it
could have name "Auto" or something, and the uniquify flag - so that MC can
perform crash-recovery by interrogating that "head".

However, this is a bit problematic to implement at the moment, because what
would that Handler head's HandleChannels method do? The only sane version, I
think, would be for it to raise NotImplemented.

This is awkward because when told to Ensure a channel that already exists, MC
will currently pick one of the Client bus names that is a Handler on the
appropriate unique name (arbitrarily), and ask it to re-handle the channel. If
it happens to pick the Auto "head", Ensure will not have its desired behaviour
of raising the window (or whatever).

That's arguably a bug - it should prefer the "head" that accepted the channel
the first time - but is somewhat fiddly to fix, and until now it hasn't really
been significant (in practice I expect that most/all? Handlers will only have
one real implementation of HandleChannels anyway, and all the others will defer
to it).

We could achieve a similar practical result at the moment by having the insides
of telepathy-glib monitor the set of TpBaseClient instances that are Handlers
(per DBusConnection), and if the last one is about to be removed, only pop up
the Auto "head" at that point. This would mean that people who "do it right"
never get Ensured channels dispatched to the Auto "head".

Relatedly, at the moment the only way to remove a TpBaseClient is to release
the last reference to it - I should file a bug for an unregister method.

I think we can safely declare that unregistering the object and its bus name
manually is not a supported action, and that only unreffing the object or
calling its unregister method are supported.