A possible solution that would not change behavior for xmp-openmpt and in_openmpt (i.e. loading the plugin without openmpt-mp123.dll would still be possible) would be to add a separate libopenmpt project configuration solely for foo_openmpt in 0.3.

Another possible option is to also use lieff's minimp3 in 0.3 and not require an external DLL at all. We don't really need any of the extra things that mpg123 can offer, and minimp3 has been proven to be very stable already and is smaller. Generally I would prefer minimp3 over mpg123 in any Windows builds also for libopenmpt 0.4.

Changing minimp3 in 0.3 is not an option: Way too much work, and more importantly, it breaks SemVer.

Also, I do not want to change the default on Windows to diverge again from the default on other platforms (and on Linux, there is absolutely no way that Debian or other serious distributions would ever ship a libopenmpt with minimp3 as the mp3 backend, at the very least not as long as libmpg123 is actively maintained, which it certainly is).

We already have other platforms that diverge, in particular emscripten. Since there's no one single solution to all platforms, I really don't see a problem there, in particular since it would help test coverage of the minimp3 implementation on other platforms than just emscripten, while mpg123 is already tested on various unix flavours and of course in OpenMPT.

r9858 avoids delay-loading of opempt-mpg123.dll in foo_openmpt. Other plugins are unchanged.

r9859 and r9860 change the packaging in 0.3