No you will still have to order things correctly, since rotating before or after a translation will have completely different results. Do you set your matrices correctly in the different matrix slots?

You can probably look at some rayt racing papers for solutions for this. They usually blend jittered images, both in time and space.

Sure it can, but at what cost? If you have the power to jitter everything in time it might be good. Sorry if I did not answer your question.

There seems to be a matrix order problem. Can you describe in which orders you do your model view operations? You might be translating before rotating, which would rotate your camera around some other point in the world.

While I agree that it's possible to implement it this way, I don't think it's a good idea. You designers cannot compose objects themselves, unless you have one über class which inherits all possible components. And while you can call update on just one component, it will not have good in-memory layout, in a composed model all component instances of the same type can be kept close in memory and iterated over without any cache misses. You are also relying on RTTI, which is something that is usually turned off in games due to performance reasons. A good sorted object layout fixes that mostly.

Also note that the OpenGL picking API has been deprecated in GL3 Core. It's still available in the full profile though.

Your solution is not really a component based solution as components are not separated from your game classes. Your instances all relies on the IS A relation (inheritance) instead of a HAS A relation (composition). Doing it the composition way (entities addresses several components) gives you a lot of advantages over an inheritance model (which is usually why you use components). Your solution gives none of the benefits of a component based solution and introduces some quirks (multiple inheritance etc). No data locality, no separate component update. No runtime modification of components.

On GL vs. D3D: There is no matrix stack in GL3/4 core, and no attrib stack. Both GL and D3D maps to the same hardware architecture, but a lot of time GL feels thinner. Sure the GL state machine is a bit of a hassle, but so is actual hardware ;) Learning any of them is fine, and as long as you understand what is actually happening you can easily switch to the other (or a console API).

OOP is not that big of a deal, not in high performance game engines. Sure it is useful, but it is often the wrong abstraction. Having good data flow, locality and memory layout of is usually better. While a lot of teams are using C++, they don't use most of C++ features. No exceptions, as few virtuals as possible, no RTTI, no STL/Boost. Why? Predicable and fast execution and small code on multiple platforms. I code in C and there are only two areas in which I would rather use C++: scoped locks and generic arrays. Not worth the hassle IMHO.