Gosh, sorry for the late response, I've been really busy in the past couple of days and simply forgot about it!

Anyways, I'm afraid I have to disappoint you. Gamestudios approach is just not versatile in any way, it's straight forward, but it's, simply put, very limiting. Rayne features a full fledged Entity system based around scene nodes. A scene node is simply an object that is somewhere within the scene graph, without anything in particular attached to it. It implements the visitor pattern, and gets it update() method called once per frame, and it can have zero or more children attached to it.
By itself, a scene node is kinda boring, so there are subclasses to it, for example the Entity class, which supports rendering of a model and which you can also assign a skeleton to. Then there is the light subclass, which, well, implements a light, and then there is a terrain class, water class etc. We follow the KISS principle here, that is, we encapsulate different logics within their own classes, and don't have a "one fits all, kindaish" gamestudio model. The problem with ENTITY in gamestudio is that, because it doesn't support inheritance, it has to play everything. An ENTITY can be a light, a terrain, an entity, or just about anything within the scene graph, and there are flags that only affect a few of these cases.

In Rayne you instantiate specific subclasses of the SceneNode class (which might be your own) (or you instantiate a SceneNode directly, which is useful in some cases). By default, they are then placed just inside the world without any attachment to anything else, but you can attach scene nodes to other scene nodes. Childs are affected by their parent, that is, if you move/rotate/scale the parent, the childs are affected by that as well. In Occluded we used that to attach the cameras to the player herself, and have the camera move and rotate together with the player, something that isn't possible in Gamestudio for example.

Scene nodes can also have properties attached to them, which is pretty much an inverse relationship; The property affects the scene node it's attached to, for example a collision hull.

Honestly, I think the way we are going is the logical way, although maybe not the one that is most straightforward. But it allows abstraction, and customization. Take Gamestudio for example, if you want to implement your own physics engine on top of it, you then have to figure out how to store the related data for collision hulls and other properties of the entity. You will likely use a skill for that, simply because an ENTITY is static in its way and can't be altered. This is an incredibly unflexible entity system, because it doesn't give you much freedom. On the other hand, if you can simply provide properties for your physics engine implementation, these properties can then be attached to scene node, allowing for a well formed entity system.