In general yes, but not in the context of Wine. Of course it's more satisfying to make the function behave better, and it's OK to do it as long as it doesn't break anything, but we can't have anybody depend on that; because if we someday find an app that depends on the garbage results we will have to put the bug back in. And that's why it makes no sense to export extensions, since nobody can use them.
Out of interest, might this apply to WineLib-specific extensions in future? As a trivial example, the KDE/GNOME system trays can hold icons have a larger size and bit depth to the one on Windows (so they look better). If you're trying to increase integration by using WineLib, would adding a new extension to allow better tray icons to be used allowed (because conditional compilation can always turn it off on windows). The alternative would be to say that you have to use the native APIs, but for instance if it was for special window hints that might not really be possible (because all your window handling code is via WineLib).
Same I guess for wine-specific window styles and so on. Presumably if such things were introduced Microsoft could bork them by introducing their own styles with the same numbers, but I think there are schemes to work around that.