obj = ObjTemplateMgr::getInstance()->createObject( "HumanTemplate", ObjIdType("Human"));
Please let the singleton die the death it deserves! Read up on the forums of why its bad. Its so rarely a valid pattern you should forget it exists, you will KNOW when its actually valid. Also, a high level event system (not huge on the word manager) would solve this for you. As a side note, I call mine a Messaging System, but that's merely a name.
//EventSystem is a namespace, SendEvent is a "global" function.
EventSystem::SendEvent("CreateObject", "HumanTemplate", "Human");
In my case my "EventSystem" is actually a class that is templated internally so you can have all kinds of messages inside a single class. So your not as limited as say inheriting from an Event class and being stuck with just a few options (send functions).
Also, not sure which article linked in your first post you liked the most but your Entity class pretty much flies in the face of the T=Machine blog posts. Which is actually the system I like the most as it is also the most generic, but yet can be nicely optimized at the same time.
Then again going overly complex in a single person project is just time your spending not making a game...
Now to answer some of your other questions:
Is a Trigger also an Entity?
I actually think no. I think something like TriggerEvent1234 should be an entity that is made up of a Trigger component, Position component and Script component. This allows a lot more complex game events to take place. Like below...
When 2 Entities are less than 10 units away from each other, something should happen (like a message or anything). Where in the code do I check whether the two Position components are 10 units away from each other? In the PositionSubSystem?
One solution I came up with as I was reading the question (not done it but think I will try it soon...) is to have the object your concerned about being close to another use the Trigger component and set its cube to be 10 units in size. I can be flat for just hits on its same level, etc. This trigger then could call its own script component and run a custom script upon being triggered.
Do I have for each single property of an Entity a component? Like Position, Target, Name, Team, ...
Yes, kinda the point. Entity should really be completely empty though you can come up with decent arguments for position but mines still separate and not a pain to access. Target and Team can be kept in AI honestly. I have a CommonInfoComponent that holds things like name and other generic info.
But for a component like Position I don't see the point of a subsystem, since there's only data in the component.
Its data, but whats wrong with that? You can have things that set/check/get (I hate putting GetX, SetX as methods instead I like readable code like int X() or void Y(int).. etc. Cleaner when you type it out. But this can verify things and allow a lot of other components to get access to it. It can also be packaged into a message (event, though think even message sounds better) and fired off.
Is Movement not a part of Physics?
Though commonly tied closely together, one doesn't exactly NEED the other and situations can be thought of when movement might not need physics.
Ok, 4 phone calls cause this 10 minute reply to turn into 2 hours. Kinda lost focus. Anyways this just my take on things. My system runs similar to what I described above. Maybe another bit of insight might help who knows.