Bascily, there should be 3 sorts of APIs exported in WINE. 1.windows apis. These dont change (some may be added or their implementation improved but the prototypes of an existing call wont change unless it was wrong in the first place) 2.internal WINE apis. These should be for WINE use only and free to be changed for whatever reason. and 3.external WINE apis. There should be a limited set of special APIs which are made available to enable projects like mono and others wanting to interact with win32 code and/or the windows API implementation in WINE. These should be specificly documented and made stable (as in, we wont changer the prototype and we wont change the basic idea of what these functions do).
For example, a function that one can call after loading WINE as a shared library to enable WINE to initalize itself. And one to do whatever per-thread stuff WINE needs to do for an existing thread created outside WINE (or alternativly a way to create a WINE thread that can then be used outside the WINE code) And some functionality to enable the loading of windows DLLs and calling code inside them properly. (this should be done so that it will work both for user dlls and also for system dlls so that you can e.g. do WineLoadLibrary("ole32.dll") and it would load the correct ole32.dll based on if the user has said they want native or builtin and then you could get the correct addresses) And whatever else is needed to enable mono, linux winamp plugin loaders and whatever else might want to make windows API calls and/or load and use WIN32 code.
If these were made stable, then apps that use them could be gauranteed that things wont break. Then, the only thing they need versioning for is to identify if a certain windows API is present or not. If it is, WineGetProcAddress (or whatever it is) will return an appropriate address. If its not, it would return an arror and you could work around it. (which may mean prompting the user to upgrade WINE).