You could learn a lesson from FreeBASIC, if you see it as a failure...

At least the way I read your post, it sounds like you are giving priority to built-in libraries over support for QB commands.

The first problem is, if people write QB64 code that uses MP3, it will not be backwards-compatible with QB; you are purposefully breaking compatibility with QB, and this some thing is one reason people here do not like FB.

The second problem is, what if the library is limited; how will people play .MOD files?
How will this be ported to DOS?
This would not be a problem if you let people select external libraries such as FMOD instead of building them in.
M$ has been criticized for building poor programs such as IE and WMP into its OS.

The big problem is, if you focus on libs and extended features before QB compatibility, you could develop forever without ever being QB compatible.
On one of my programs, I ignored bugs and focused on adding new features.
Now that program development is postponed, and the bugs are still there.

The main QB incompatibility in FB is 16-bit low level functions / ASM, and you won't be much more QB compatible until you support those.
FreeBASIC ignored this problem and has essentially (but not officially) decided it will never be worthwhile to fix this incompatibility.
If you don't set the #1 priority to these challenging compatibility issues, your project will end up just as incompatible as FB (with some Blitz Basic like libs for good measure).