The problems with this concept have already been discussed (such as calling conventions).
This is a problem for trying to expose a linux .so as a windows .dll, as the interface is almost never identical. It's not a problem for a program that is explicitly written to use a linux .so.
I believe all of those things have been looked at already, and generally has been decided that it's not the "right" solution, and that it really doesn't belong as a part of Wine's source tree.
Except that the "right" solution (using wine_dlopen and friends) turned out to be impossible.
The "most correct" solution is to distribute Wine binaries, Windows binaries, and a Winelib wrapper all together. Failing that, one should distribute only Windows binaries, as Winelib binaries won't work across Wine versions.
An interface to Linux libraries that Windows binaries can use and be binary compatible across different Linux and Wine versions would be a useful thing.
Even if we can't have it in Wine, an open source winelib bridge for this (so that a user can supply a version that works on his own system, and to avoid duplicating the work) would be nice.
Well, can a native Linux lib be loaded on Windows? After all, Wine is an implementation of Win32, not a series of hacks to integrate Win32 into the *nix-based host system.
My opinion on this particular issue doesn't matter, but we don't strictly prevent Windows apps from seeing the underlying Linux environment. Any app can make linux system calls, access the filename conversion functions, invoke linux programs, and access the unix filesystem using a wine-specific shell extension.