[David Elliott explaination snipped]
Thanks for explaining what Patrik has been going on about.
Yes, it was quite a good explaination.
However...
In summary:
Consider a proprietary application which ships as a proprietary library which is statically linked with LGPL libraries at install time in a way that lets users supply new versions of the LGPL libraries. This lets them fix bugs in the LGPL'd code and thus in the proprietary app. The harm you see is that a vendor could, once he found a Winelib function with a bug, simply do his own clean-room implementation of that function, and use it instead of the Winelib version of it, and keep the improvement to himself -- which would also deprive the user of the ability to fix bugs in the proprietary reimplementation of that particular WineLib function.
... while this is an entirely possible scenario there is little profit in doing what you suggest so while it is one of the holes in LGPL it is not really a problem in pratice I think.
No, the problem as far as Wine is concerned, is that somebody might do proprietary extension of some important part of Winelib that enough people want so much that most people uses the proprietary extension and under such circumstances there won't be any incentive for people to work on Wine.
However, I neither believe this to be true, nor do I believe that the LGPL will help to stop it other than very marginally.