I like the idea, but I think most users never would/could author their own UI's, and many who could would only want to a small percentage of the time.... but maybe your idea could work if there was essentially an API marketplace AND a UI marketplace, and services competed on both of them seperately... v1 from a service would (probably) always offer both to be usable but if it published some contract for how they talk to each other so they were decoupled and anyone could author a new UI (and, I suppose if it were a marketplace, sell it, but maybe given constraints only selling the API is realistic and UI is more FOSS/enthusiast driven/fork based?) and make it discoverable as an alternative to try out.
I think having a distinct separation between back-ends and swappable front-ends would be a good thing, but by this point, it would require government intervention to make it happen. Twitter, Facebook, etc. froze out third-party clients to protect their advertising revenue. They're not going to let third-party clients back in unless they're forced to, and such a move by the government would be tantamount to declaring war on the advertising industry, so, it's not likely to happen.
I agree with your points here, and I think two markets - service API market and client software market - would be a great thing to have. One of the things that makes a lot of services suck (social media platforms in particular) is the control they have on APIs they provide. To pick one example, I can sort of use the Facebook API for some of the things, after jumping through enough contractual hoops, but I can't really go and build a Facebook client that would have feature parity with the official one. Not without risking my account getting banned. I especially couldn't distribute such a client either.
