Current Tp-Qt4 Client channel handling is done via the Client{Observer,Handler,Approver}Adaptor classes in ClientRegistrar internals, calling to the application AbstractClient* subclass virtual handling method implementation. Before calling that, though, the Adaptor D-Bus method implementations create Account, Connection and Channel objects corresponding to the object paths indicated by the method parameters. The objects are always created anew, even if there is an existing Account / Connection proxy for the same D-Bus object.

In addition to causing needless re-introspection, this leads to the Contact objects and handles from the Connection supplied to the application handler method implementation not working with the application's existing Connection (which is probably where the application has retrieved any current contact list contacts, etc.).

Tp-Glib always does ensure_account on a bus-connection-wide pseudo-singleton to get existing Account objects, if available. The meta bug #29451 contains relevant discussion on semantics, including whether we should do the same in tp-qt4.