Also, I'm not a fan of engines, but if you would recommend an engine(for example irrlitch) I guess I'll check it out and maybe try to code on it - it's just this is not really my goal. And speaking of goals - to get a better idea of what I want here are my goals:
How can you not be a fan of game engines when they can save you years and maybe decades in your learning? Game engines take 5 to 10 years to develop well and a team.
Using an existing game development engine is like acquiring horses, training to use them, and putting them to work. Making your own lower level software is like compounding the difficulty by breeding your own horses from birth, then breeding with other horses, training to use them, and putting them to work.
Everything about your first post shows that you want to build the infrastructure or logistics (lower level pipeline) without having first learned the vehicles (games) which use them. The attempted shortcut here will actually result in far more time to develop a game engine than if you learned game development first. Another way of looking at it is that you are trying to develop the rocket launch facility (game engine) before understanding rockets (games).
Game Engines List:
Learning on a game engine for at least a couple years is a REQUIREMENT if you want to avoid adding years to your confusion. Consider using an existing game engine as school for thought and be dedicated to learning one well.
1) Get better at C++(obviously I would need it for pretty much everything) This is incorrect perception. Some programmers, game developers, or even game engine developers have published little or nothing for games in C++ and with much success using other languages. You really need to read threads on other languages and look at other game engines not using C++ to balance your research. In the broader picture of things, C++ is not required, but may be preferred by some coders.
2) Learn OpenGL and DX programming (and I'd rather have it low level and not through and engine or whatever) Here is another misconception. Game engines have interface between the developers and the machine/assembly language as does OpenGL and Direct3D, but game engines vastly increase productivity by a multiple factor compared to raw lower level coding. Using only the graphics APIs will result in much more work to develop a certain high quality game compared to using a game engine.
A better strategy long term is to use a game engine which integrates with graphics API coding (OpenGL and Direct3D) in the development pipeline.
3) Make my own software renderer and raytracer (as an insight in how things work) In many cases, these two are totally unrelated to the development of certain games. These methods of implementation are CPU and GPU resource intensive to the point of only being used sparingly in games due to hit on performance. Indeed, world class games continue to be made with no raytracing or custom made renderers, the majority being the case. Do you want to add another layer of difficulty and years of delay to your development goals?
4) Try out various physics engines like Tokamak and Ode - best of all understand how they work and write my own just to get the idea about it. This is like wanting to develop your own boat just "to get the idea about it". Existing libraries have all major languages covered in physics and it would take you 5 to 10 years in game development, engine development, and tool creation experience before you catch them in the race. They have a huge head start on you, basically having accomplished what is needed in the way of physics engines. Odds are that you will never reach them in quality and development friendliness.
5) Learn more on Windows API This is useless for many (most?) games. If you want to specialize in Windows game development then there is nothing wrong with this strategy. If you want your software to be cross-platform in OS and hardware then this is a detour to the desert.
Any constructive advice and criticism are welcome!
I like that you think and feel big. Lofty goals are generally good to have, but you need to make 5 to 10 games first. You need to understand the coding of games in order to make the lower level framework that you want, again - first. You want to make a sea port without first knowing the specifications of the vessels which will use it? I think not.
Develop games for a couple years before you go trying to make a framework.