結論的には、Wineを改造しても Windows API の仕様を変える訳ではありませんので、
もし、Wineの一部であっても、Windows API だけを使った dll の部分は、Wineの
バージョンが変わっても、原則的には自由に入れ替え可能な可能性があるのです。

kernel32.dll, gdi32.dll, user32.dll, ntdll.dll の4つの dll 以外のdllは、
WINEの内部がどのように実装されているかには依存していない可能性があると
いうことです。もしそうであれば、Wine のソースを改造してもこれらのdll.so以外は、
本家Wineが今後発表する新バージョンのものを、改造 Wine のバイナリファイル群に
後から上書きしても、互換性が保たれ続けるんじゃないかな、と思いました。つまり、
以下の 4つの dll.so だけを配布すれば、かなり長い間、独自の Wine として動作
できる可能性があるのではないかと。loader.c を修正した libswine.so.1.0 を配布
すれば、dll.so の検索パスも上手く「オーバーライド」できますので、以下のたかだか
18MB程度のファイル群を配布しさえすれば、標準の Wine を壊さないまま、独自の Wine を
特定のアプリにだけ適用し、両バージョンの Wine を共存できるのではないかと思えて
きたんです。

./libs/wine/libwine.so.1.0 1,933,464 # WINEDLLPATH 修正のため
./kernel32/kernel32.dll.so 5,526,999
./gdi32/gdi32.dll.so 2,655,524
./user32/user32.dll.so 4,267,471
./ntdll/ntdll.dll.so 3,256,245