"Android iOS, OSX and Win8 are built on top on NeXTStep bundles idea. They quite explicitly don't track dependencies. At all. The whole store is flat: you have libraries and capabilities in the OS and application use them to talk to each other. They don't use capabilities from other bundles directly."
I should have re-phrased my sentence. The app stores do not handle dependencies, they leave that up to the individual apps. Nevertheless, it is through them that apps have access to their dependencies, and then depend on them being present in the app store. If you build an Qt app for Android you will experience how this is used to pull in the Qt libraries. Problem is that this model is much more fragile, since you leave it up to packagers to handle all dependencies. That model simply does not scale. I repeat, the devil is in the details, you are mixing the dependencies which is a back-bone of open development with ABI breakage. For meaningful discussion we will need to separate between the two.
"This is what makes it possible to create a store with 500'000 applications faster then Linux could build one with 50'000 applications."
I beg to differ. There are far more linux applications than 50.000. I haven't checked, but Debian shouldn't be far away from 50.000 in the official repos by now. If you are familiar with what it takes for a pacage to enter Debian, you would now that you are badly mixing apples and oranges here. Bring in all the ppa's of ubuntu, and you have something more comparable. Then take into account the open development model, and you see how we avoid the 499.000 utterly useless apps. Even with a tiny tiny fraction of the attention, the widgets available for KDE already rivals the ones available on Android (my personal opinion of course). The point though is that proprietary applications are not tailored for in Debian. Ubuntu has adapted their software center for proprietary applications, so it is finally offered, but admittedly still in it's infancy.
"LSB is nice piece of technology but it's totally unsuitable for real-world applications. For example it still does not offer a way to play sound or video"
No, it doesn't, but it pretty much takes care of the ABI issues for most other standard libraries. Maybe I was not clear on this, but addressing sound and video in my post directly was exactly because LSB is not very helpful there. I agree though that media dependencies should have a place in LSB too.
"ALSA or PulseAudio don't work this way. You need to somehow find the configuration and/or daemons before they'll work as user expects."
ALSA has done hoops to cater to compatibility issues, supporting OSS based applications for instance. Still programming against ALSA is probably a bad idea, which is why I did not list it. I did mention Gstreamer on the other hand. Pulseaudio is a server, so I am not sure exactly what grievance you have developing against it. Along with Gstreamer I can also add SDL. Both should give you sane ways to provide sound in your applications that by now should be quite robust between linux distributions, and even across operatingsystems. Which is more than I can say for the alternatives on other platforms.
"How can I create applet for a KDE panel which is usable on all LSB-based distributions?"
The KDE desktop has been a rather fast moving target lately, I would even say partly due to proprietary development of Qt. If you are happy with the approach taken by other platforms, i.e., using a fixed low performing high level language, you can do it in Python quite easily and expect it to provide your precious stable ABI to kingdom come. If you do it in QML, chances are you are in luck. Qt is moving to an open governance model, and with it I expect a relatively stable ABI. In my book, linux has had a stable ABI. It is the drivers that don't have a stable binary interface, and I think we should be happy about that.
"most of the pieces needed to build stable Linux desktop ABI are there."