You could also add an optional 'convenience layer' over the lower-level flexible-but-inconvenient core library, as long as the core library can be built and used without the convenience layer.
In essence it's just a way to decouple the actually important library functionality from runtime environment details which might be better implemented outside the C and C++ stdlibs anyway.
It's already as simple as the stdlib IO functions not being asynchrononous while many operating systems provide more modern and performant asynchronous IO APIs. For a specific type of library (such as an image decoder) it's often better to delegate such details to the library user instead of either using the stdlib or having the library talk directly to OS APIs.
PS: this type of library design is actually also quite common in game development, because such libraries must be embeddable in game engine code bases which usually implement their own IO-, threading- and memory-management systems.
Dear ImGui is a C++ example: https://github.com/ocornut/imgui
You could also add an optional 'convenience layer' over the lower-level flexible-but-inconvenient core library, as long as the core library can be built and used without the convenience layer.
In essence it's just a way to decouple the actually important library functionality from runtime environment details which might be better implemented outside the C and C++ stdlibs anyway.
It's already as simple as the stdlib IO functions not being asynchrononous while many operating systems provide more modern and performant asynchronous IO APIs. For a specific type of library (such as an image decoder) it's often better to delegate such details to the library user instead of either using the stdlib or having the library talk directly to OS APIs.
PS: this type of library design is actually also quite common in game development, because such libraries must be embeddable in game engine code bases which usually implement their own IO-, threading- and memory-management systems.