The camera sprite idea is honestly a terrible design choice. A sprite, by definition:
“a computer graphic that may be moved on-screen and otherwise manipulated as a single entity.”
The camera is NOT sprite, and should not be allowed to behave like a sprite. The camera is a special component; its not an entity or a sprite. Its not rendered, and in fact it doesn’t do any of the rendering. The camera is simply a way to determine what is, and what isn’t inside the frustum and projecting vertices onto the screen using matrix math. Cameras do not move, there is no such thing as a camera. The geometry moves within the window.
I agree with saucymeatman when he says having a static world is a bad decision. There’s no issue with having the user create a world object. A static implementation just confuses everything and makes stuff way more complicated then it should be.
Honestly? I think your library needs a lot of work to make it more user friendly, and you need to research design templates. There’s a reason programmers use the same code templates, they work well and do their job.
I also have an issue with getting components using a string. There’s just something very wrong about that, use getters.
Keep it up though! Don’t expect a lot of feedback from such an early version of your library though. People already have the libraries they need, breaking into the game engine/library market is hard unless you are very good at your job.