In case you haven't noticed, I have contributed to the opensource unmo3 myself, and I can tell you that the code quality is so abysmal (probably because it's just a proof of concept) and full of security issues that rewriting a decoder from scratch would be a better choice. Plus, the open-source version of unmo3 doesn't actually do any of the MP3 or OGG decoding, so it's incomplete too.
libopenmpt can already make use of the closed-source version of UNMO3 by defining MPT_WITH_MO3.

I also favour a new from scratch native parser for mo3 in OpenMPT/libopenmpt instead of completing and fixing the open source unmo3 library. The former would probably also be less work in total.
The closed source unmo3 by Ian Luck is obviously no perfect solution for libopenmpt as it naturally only works on platforms for which Ian provides a binary. However, in its current form, the open source unmo3 library is no option at all for the reasons Saga Musix already pointed out.

Thank you for your detailed explanation.
With all of your answer I still cannot find any conclusion for my report.

Do you have any plan to developed mo3 codec from scratch in any near future? or
Will OpenMPT and libopenmpt still depend on unmo3 by Ian Luck?

If the answer for the former question is "no", my hope is you don't mark this report as won't fix and let it be open until somebody else take care for this report.

Best regards

There are no plans to do so from my side.

I currently do not have any plans for working on this either, but I do consider the feature request valid and would also like to see native mo3 support sometime in the future.

I never work with mo3 files, but I double-clicked on one from a CD game to listen to the music, and OpenMPT opened it without a hitch. It was pretty basic (like a MOD file) but I was able to listen to the track.

So apparently SOME compatibility is available by openMPT. Let it be known that mo3 files might at least be accessible by openMPT.

The focus in the feature request is on native, built-in support for MO3 files without relying on the closed-source unmo3.dll/unmo3.so, especially in the context of libopenmpt. For OpenMPT it's less of an issue, but using the closed-source unmo3 can cause licensing problems when wanting to use a completely free library, and in general libraries depending on other 3rd party libraries are always a big hassle.

In a state of coding frenzy I started working on an MO3 loader last night, and pretty much everything apart from sample loading is done.

Glad to hear that.
Thanks for your nice effort Saga.
You are really a nice person.

Decoder implementation is now complete. Integration into the build system (mostly #defining some flags and searching for libmpg123) for libopenmpt is still left to do for the next major release.

I implemented most of the build system changes for libopenmpt on the major desktop systems. Android, Emscripten are not done yet.
libopenmpt now (r5996) uses the internal MO3 decoder by default on Windows and on Unix-like systems.
Decoding of MP3 samples is done using libmpg123 (provided externally on Windows, linked directly on Unix-like systems) or MediaFoundation (on Windows 7 or later). libmpg123 can also be loaded dynamically on Unix-like systems.
Decoding of Vorbis samples is done using libogg, libvorbis, libvorbisfile (on Unix-like system) or stb_vorbis (on Windows or if libvorbisfile is not available).