Comment 5 for bug 1602159

This new API has only a couple of users, and I'm quite sure they'll work fine with your changes.

There's indeed an issue with the change notifications being sent to all clients (I just filed bug 1603412 about that), and possibly confusing them -- your patch should help in avoiding ending up in an inconsistent state.

About the pseudo code I suggested, indeed it's making a signal connection for each Manager object, but I suspect that given that they are all targeting the same "service/object path/interface" triplet they'll be squashed into a single connection in some layer below in the D-Bus stack, so they won't pose an additional burden on the D-Bus service.

Please note that, even if we add your patch (which is actually needed for solving the notification handling issue), the main -- and I would add, *only* -- goal of the library is to support clients represented by *single* .application file. Unconfined clients which perform the authentication on behalf of a *single* click application also fall into this category, but anything more complex than this doesn't.
So, given that your project doesn't fall in this category, you are welcome to use the library if it fits your goals, but if it doesn't, I'm not inclined to extend the API with functionality that would not be useful for a click application.

The reason I'm writing this is that I suspect that online-accounts-api (even with your patch applied) is still too limited and not suitable for your goal, unless you go for the pseudocode I wrote above: how will you find out the service IDs you are interested in?
Normally, they are encoded in the .application file shipped by the app, and online-accounts-api internally figures that out; but it doesn't expose any methods that would let you know what service types are supported by an application.