This is great. Especially that topic, just the day before yesterday I had a look at several articles concerning component-based game design 
Good timing then.
The third approach (self-attaching components) looks interesting, but it sounds too good with this short description.
I was afraid it's not explained enough. I think a second part that covers some more implementation details or more detail in general would make sense. Besides that, I have a working implementation of the approach in a game; so it's nothing in theory only.
The behaviors still need to access the properties somehow, how is the recognition "automagically" performed?
Yes, the controllers do access the properties of entities, because that's what they are working on. The automatic attaching works by defining rules in each controller that tell what properties it requires. I will cover all of that in part 2.
Some remarks: You write "leave a commit" instead of "comment" (too much Git recently? 
) and the example EntityFactory::create_tree() doesn't return a value.
Not only recently, but always.
Thanks for pointing it out, both mistakes have been fixed.
Apart from that, the text is well-written, without much bla bla, and easily understandable. Continue like this!
Thanks for your feedback!
@FRex:
No, inheriting from multiple classes results in one single class. That's why it's problematic, especially when different base classes have one equal ancestor. I personally think it's okay (and required) for inheriting interfaces or utility classes. But inheriting from two full-blown classes is mostly a design flaw in my opinion.
