My current issue was(is) with passing the information within the components. I'm not sure how this separation of systems would help.
Physics and rendering are low-level systems or wrappers.
The components systems settle at the highest-level module of the engine, which you can consider being the game module or the engine module. I would call the engine module since it brings all lower level system together.
Whenever you hear the word game entity you should think about working at the engine module level. The same thing obviously applies to an entity-component-systems.
What I'm trying to let you understand is that component systems are not modules by nature. You can implement with no problem component systems do limiting them to be high-level systems that uses lower level ones such that there are no dependencies. This helps when creating the overall high-level architecture of the game engine level by just connecting the dots.
As a side note, if physics is your stuff, play with some physics API first!
Agreed. I got a vote up indirectly.
If you use Bullet Physics or Box2D then the physics system works like some kind of high-level interactivity of the user and the physics world; the physics world it is already implemented in both libraries and you should avoid duplicating functionalities.
If your renderer works like a scene manager or a game world I have no words here, but if is a low-level graphics wrapper then things will be quite complicated in the future when you do more advanced stuff like cross-platform support, because the system depends of the game-object components.
The game object manager looks like a scene facade class and probably most of the time containing game objects/actors/entities/whatever is in this category; this is more correct than calling a class "the render system", creating components such "renderables", etc. which would be quite complicated to generalize this since its small functionalities differentiates a lots sometimes.
That said, thats what I would do if I had your architecture:
Separate systems into low-level ones and high-level ones such that you know what a module, a system, and a sub-system is;
Review your classes responsabilities and functionalities;
See if you can port any other external library such a physics library with no problem to the component systems;
Interesting how people tend to implement their ECS such that every system replace a functionality that could be easy and correctly implemented separating into low-level modules and high-level modules. IMHO separating responsabilities is a tool that can be used to switch from ECS and the old game-object model such entities or the simplest OOP design.
The main idea of the ECS or the game-object component system is that you should avoid inheritance when possible by just using the "plug-in the component" approach. It doesn't mean that you must aways create a component to every type of system, it is just an way of organizing the components such that the entitiy is just an ID, of course with a lot of optimizations in order to be fast, compatible with script-systems and event based games (tough games are not event based), etc. It also solves some problems with weird class inheritances; but since that's run-time you can most of the time skip that and duplicate classes functionalities.