With namecoin one can bootstrap DNS/domain ownership. so one can run a server by using foreign, trusted build scripts on a VPS platform (AWS, Rackspace, etc.). SSH agents are also kind of like this. in the end one can use one master key for everything.
I think that's the possible awkward part.
It's not possible (or not that I understand) for the client to know what adapted version of the server-side source code is being used. If you have a bad actor running the server, they know how much their HNW clients have in their accounts. This could motivate them to expend alternative (real world) resources to ensure that the paper backup or the wallet seed aren't available to the client (somehow). If the bad actor server can do this in a way that does not implicate their complicity, could they extort money from the client by pre-implementing server side code that refuses to derive a new address chain, or that refuses to sign transactions to access his lost funds?
All of this let me think that I must separate the communication part and the more higher level services for the server. So in fact we will have each merchant installing their own server on their domain that handle the basic level of communication and generating addresses for the client software, and for all the higher services that require some form of centralization like CoinJoin operations etc, there will be independent services providers that each client software can subscribe to from a public list. For the general user they must still pass through a trusted server if they don't want to/cannot maintain their own server.
We can also imagine a much more "decentralized" model where we have light clients that can just connect to a merchant's server when sending payments and without email(xmpp) address for themselves, but can still benefit of all the ecosystem of high level service providers on the whole network, thus making this project really a "communication layer" / "service hub" for "Bitcoin service providers" / "software agents". So basically we don't need a third party to mess with our BIP32 addresses...