This is a bad analogy, because Wine also has dependencies on various "Linux APIs". So technically if you maintain Wine you are also maintaining all the libraries Wine depends on, and so on.
It would probably be easier for a game to just target the libraries Wine depends on, or even better, some smaller and more "least common denominator" abstraction layer (e.g. think libao for audio) sitting on top of the same libraries. While you can see Wine as de facto providing such an abstraction layer (e.g. you can switch audio drivers, video drivers, etc. in Wine), they are forced to expose an API whose evolution they don't control (Win32), which is something that long-term is doomed to fail.
> So technically if you maintain Wine you are also maintaining all the libraries Wine depends on, and so on.
You are confirming that it is a good analogy. If some lib changes its ABI, in the wine case you need to fix it once: in wine. If you have 2000 Linux ports of games, you need to fix it 2000 times.
Your libao example is exactly the problem we currently have on Linux. Nothing is really stable, api and abi breakages happen almost everywhere. You can be careful and pick projects that promise to never break abi compat only to still get disappointed by at least one eventually.
And while win32 is not under your control regarding new features, it is by far the most stable userspace api and abi in existence.
The problem is maintaining long term compatibility which is what Wine is doing. Native Linux ABIs can break (soname changes and etc.) and unless someone keeps translating old ones into newer ones, it won't work.
I.e. something Wine-like for Linux ABIs themselves that games use would be great.
It would probably be easier for a game to just target the libraries Wine depends on, or even better, some smaller and more "least common denominator" abstraction layer (e.g. think libao for audio) sitting on top of the same libraries. While you can see Wine as de facto providing such an abstraction layer (e.g. you can switch audio drivers, video drivers, etc. in Wine), they are forced to expose an API whose evolution they don't control (Win32), which is something that long-term is doomed to fail.