That's more or less what I was referring to when I said tweak their policies.

You make some good points, points that I'm familiar with seeing discussed elseware. One of the points that you make that I think may be the largest reason is that Linux isn't user friendly enough. There's not enough automation and it takes work to get things done, especially for novice users or users that have no inclination to work through the issue of getting what they want. The majority of folks aren't going to deal with building packages and dealing with dependencies, for example, whenever they have easier alternatives like Windows.

Some of these issues may be remedied by 3rd parties if the OS can ever capture enough market share.

The respect offered by Linux is the help of the community. Free help from peoples on their free time for non-commercial distros and support like Microsoft could provide it as a long-term for commercial ones (Red Hat for example).

What you underline with your link for example isn't a packaging problem at all, it's a problem of distros choosing to offer at regular interval a new major version of the distro and so just provide security updates after release of this version so that you need to wait next major version to get newer program's version. Solutions are multiples :
- Wait the next version of your distro (can be long for some of them)
- Use alternatives repositories (PPA for Ubuntu, rpm-fusion & co for rpm-based distros etc.)
- Use rolling release distro like Archlinux which is updated really fast compared to lots of others
- Do manual install of newer version based either on standard distro package or standard tarball. The worst in my opinion as it's a lot more work to keep everything up-to-date for example.

The problem is the base architecture & the current understanding how software works in linux: in the current dominant linux distro design the distros feel responsible for packaging and integrating the software and don't care for ISVs or external compatibility. This distro system is built around the repo, means tight coupling of system and apps, the separation is extremely weak. And this means typically also that the update cycles of the system and apps are synced, means outdated apps as long as the distro don't upgrades or update enforcement on every distro update. Also by sheer number of integrateable apps in a distro system seems to be limited to 10.000s of apps...beyond that this integrated enourmous blob called repo is not maintainable anymore (for comparison windows ecosystem has millions of apps, android also). This would be maybe standable if we would have only one distro....but we have hundreds multiplying the needless effort, creating a highly incompatible ecosystem. Also, distros are closed circles... if debian decides your software is not in, it is not in, unlike windows where everyone can address windows. So, distros repos are not some kind of app store like android with easy placing of software by arbitrary third parties. As the distros are focussed on their repos the possibility for external software integration is weakly developed. Or, as Ian Murdock summarized it wisely: "the key tenets of open source is decentralization, so if the only solution is to centralize everything, there’s something fundamentally wrong with this picture."

Windows and a platform system decouples system and apps, defining stable interfaces and care for binary long time stability. This gives the easy possibility for arbitrary application development, deployment and updating to third parties... ISVs. This system was proven to work extremely well and ended for windows with a ecosystem of millions of high quality software products with excellent long time compatibility.

The platform provider (MS) cares for the stability of the platform and interfaces, the ISVs cares for updating the apps and rely on the stable platform. On linux, the ISVs can't rely on nothing making it pretty complicated to address "linux" with external binary software like games..

("PPAs", "rolling releases" and "distro hopping" are inconsequent ugly hackish approaches with significant downsides... real solution approaches are "self contained bundles" or "half-rolling release systems", both would also need efforts by the ecosystem ... currently Steam seems to push the distros in this direction)

So, to start with this, looking at http://www.debian.org/ they've currently 37.500 official packages. It's over the 10k limit you're talking about.
Archlinux provide more than 10k packages in official repos and more than 40k in AUR. Still more. These were two examples

You think rolling release PPAs & co are ugly hackish approaches? Look for example at http://deb.opera.com/ this is where Opera Software, the editor of the browser with the same name provide a deb repository to users and they can freely use it. Mozilla have their own repository too and I think it can be a good thing.
About rolling release, I tested it on Archlinux, explain why do you think it's a bad approches? For my part I don't think so as you don't have to care about system upgrades anymore : you update regularly and that's all.

About decoupling the distribution and so on : Microsoft as Apple are slowly moving to a totally closed way of distributing apps where you'll only be able to do it through their app store with all the limitations belonging to that choice (some peoples for example some devs on Mac OS are really angry about this and have to remove some features from their apps.

Finally, the approach where apps and every requirements are encapsulized in on package isn't a good idea. Some distros still use it (Slackware) because they use a very old and bad design. Why ? Difficulty about maintainability (if all is centralized in a package manager, it's easier to care about), conflicts, disk space (multiplication of copies of same components means that much more space used) memory management : different copies of same library on disks means that much different copies in memory if you run them.

To be short : it's inefficient. That's one of the reasons why to manage memory and because I used all of these OSs, on the memory management point Linux > Windows > Mac OS (Windows have some common resources that OS X don't have. They package inside their .app more things than Windows in their software folders). So, of course, there are other reasons (swap management for example), but I still tell that, at least for me, it's a bad idea of design (and looking at the choice of most Linux's distros and most BSDs, they've the same opinion).

PS : Slackware is very old and maintained by only one guy. It can an explanation.

I only considered Programs available in repositories. It still exists some of them outside of repositories. But it's true it'll remains a lot less than on other platforms. Why? Because peoples think they've less possibilities to monetize on this platform…? It's partially true as you often have equivalent for free. Because they don't care about an OS with that much little market share? Probably more true. Don't forget that the more market share an OS get, the more peoples want to develop on. Money perspectives.
But I don't think the structure is the problem. Why? Because if more peoples develops, and works on these platforms so it'll in the same time have more peoples to control, check, validate and so on. Meanwhile, they still can
- Provide their own repositories where they've control on everything outside of the official ones
- Provide packages without repositories like they do on Windows or Mac OS X
- Provide binaries so that community will prepare packages to use the binary.
- The best one, but sadly impossible as most of the companies are against : make it free (as in freedom) or open source. The community will do the remaining job for you with pleasure.

Repositories more closed than alone programs? Of course! They've to pass quality check to avoid problems to users that they could get. But you did the wrong comparison.
Compare .deb, .rpm, .tar.gz and so on files to .msi or .exe you get on a separate website. This is comparable and the same on both platforms.
Or compare repositories to these new appstores which had no equivalent before. And repositories will be more open as they've no censor. Just quality and stability check. Or abusive rules like Apple which forbid apps which have the same role of their apps on iOS.

Moreover, mobile OS were fast seen by lots of peoples as gold mine to get lots of money very fast.
I'd be curious to have statistics on available programs on desktop OSs, but it's impossible.

Not if you consider they run different versions because they don't care about updating libraries because "the current one works well".

GOG representatives said in the past, that the main reason it's hard for them to figure out how to support Linux is long term support. So what this "long term" really is? How long do they support Windows games for? 5 years, 10 years? Even more? Without defining what long term is, there is no way for us to understand what GOG really finds hard to do.

And it looks like XCOM: Enemy Unknown is pretty much confirmed for Linux now: http://www.gamingonlinux.com/articles/xcom-enemy-unknown-looks-set-to-hit-linux.2746

Will it be DRM free, or another one forever Steamed title?

Well it's published by 2K Games and already a Steamworks title so it will most likely remain so on Linux. But still, it means that yet another big developer/publisher is taking an interest in Linux while GOG continues to ignore it...

Steam-locked developers are irrelevant for GOG anyway. But I agree with your point that GOG is too slow.

Problem is. People are assuming linux take up especially games will take off. Not necessarily guaranteed

Linux gaming already took off. The point of doubting if it can already passed, it's not an assumption it's a fact, which HB and others successfully use. So GOG is already behind, and their reasoning about support will become more and more weird with time.

Well, I would argue there is strong shift to cross-platform, indie, "open"(-source) and in general alternative technologies & structures.

While the linux ecosystem IS the best known alternative technology from this "alternative" domain, it is not well suited to fit the technical expectations in the desktop and gaming domain. And I don't see a shift to unixoid computing structures nor to GNU-extremist free structures, like it it is fantasized since the 90s. How MacOS used the BSD kernel, Android used linux or now Steam uses the underlying ecosystem is a strong shift away from typical unixoid, source and hacker focused linux ecosystem structures. For instance, ReactOS would fit better the general trend and request for an alternative, open platform while being a real platform for gaming.

But in general I agree, GOG should do something instead sitting passive and supporting the legacy platforms only. Either supporting linux in a minimal way at least (dosbox images) or being a trendsetter and supporting something more appropriate: a free platform alternative to Steam, the Wine-platform or ReactOS (or like DotEmu android).

The minimal would just be…to provide games already running on Linux, like most of the HIB games which are here : VVVVVV, Incredipede, Hotline Miami, FTL, Don't starve, FEZ and so many others…
All those games already have a Linux version and even a DRM-free Linux version, so why just don't provide it as is?

Same about the brand new game available since yesterday for example, Dust Force. Already available on Linux with a previous HIB.