Just a little inline comment on the documentation.

Could you attach a blend file that demonstrates the new functionality? It'll be needed for the release log anyway.

If the other argument can be omitted, I'd rather see it as an optional argument.

We looked at that yesterday, @Porteries Tristan (panzergame) is working on it. There is still an issue with the layer number, as newly added layers are moved to the reference object's layer. Without such a reference object, this move cannot happen. For lights this is not a big issue, as light objects expose the layer property. @Porteries Tristan (panzergame) is investigating exposing that same property for KX_GameObject too, comparing it to adding a layer argument to the addObject method.

As disused on IRC moving the get/set attribute to KX_GameObject is not needed. You only need the changes from KX_GameObject.h and /KX_Scene.cpp.

I'm actually in favour of Tristan's patch.

One advantage of making KX_GameObject::setLayer() virtual, is that we no longer need this kind of code:

(*git)->SetLayer(groupobj->GetLayer());
// If the object was a light, we need to update it's RAS_LightObject as well
if ((*git)->GetGameObjectType()==SCA_IObject::OBJ_LIGHT)
{
    KX_LightObject* lightobj = static_cast<KX_LightObject*>(*git);
    lightobj->SetLayer(groupobj->GetLayer());
}

where (*git) is a KX_GameObject *. The code doesn't use the virtual language feature that C++ offers us, yet tries to implement the functionality of virtual by itself, and only for a specific subclass. This pattern occurs twice in KX_Scene. IMO, this is crazy enough to actually start using the virtual keyword, as the current situation just adds code bloat and confusion. To me it's hard to see what's to lose by improving this situation.

Furthermore, it's nice to be able to set which layer is lit by a lamp, but what is use is that when you can't move the objects that are actually supposed to be lit to that layer? If that is not what we're aiming at, then I wonder why there is a KX_GameObject::setLayer() method at all.

@Sybren A. Stüvel (sybren)

One advantage of making KX_GameObject::setLayer() virtual, is that we no longer need this kind of code:

(*git)->SetLayer(groupobj->GetLayer());
// If the object was a light, we need to update it's RAS_LightObject as well
if ((*git)->GetGameObjectType()==SCA_IObject::OBJ_LIGHT)
{
    KX_LightObject* lightobj = static_cast<KX_LightObject*>(*git);
    lightobj->SetLayer(groupobj->GetLayer());
}

Did you looked into my patch? Because I also made exactly this changes. I removed this code and changed KX_GameObject::setLayer() to virtual.

I digged not much into the lighting code, so maybe I am wrong. But as far I have seen KX_GameObject::setLayer() is used to store the object layer which is later compared with the light layer to define wich object has to be light by this light. So we only need to set this layer with KX_GameObject::setLayer() only for mesh objets that could be light. For Lights we only need to set the layer in the Lightobject with KX_LightObject::setLayer(). Sure we can set the KX_GameObject::setLayer() to, but I think actually it is not necessary, because a light can't be light and for the moment we don't have an API wich returns the actual object layer.

If you want to set the object light layer to, then this should be done in an extra patch, because the new "addObject in python without reference object" feature patch has nothing to with this changes.

Also the wrong layer check should be done in an extra patch.

No offense to @Sybren A. Stüvel (sybren) or @Thomas Szepe (hg1), but I'm a little concerned that this was committed without a review from @Campbell Barton (campbellbarton), @Dalai Felinto (dfelinto), @Daniel Stokes (kupoman), @Benoit Bolsee (ben2610) or myself. While the patch overall looks okay (thanks to feedback from reviewers), there can be subtle details which newer devs might not notice. On the other hand, this patch has been in the tracker for almost a month and I didn't get around to reviewing it, so I'm glad things are at least moving along.

Moguri. Your comment comes a little bit late. Against Campbell's rules we only need two reviewers for new features as long it don't touch Blenders core http://lists.blender.org/pipermail/bf-gamedev/2015-February/000486.html.
I didn't know that you want to review this patch. Because there are some patches out there which are waiting since years for your review (example 7 Aug 2013 T36388 --> D1205), so I thought you don't will review this.
You were also assigned as reviewer since 5 April. Also there where six days between Sybrens OK and you don't gave any comment or added other reviewers to it.
I think that should be enough time to write a little sentence like "Please old on, I want to review this first" or add Campbell as reviewer. If you would have done this, I would have waited with the commit.
I also don't want always to add Campbell as review for such simple patches. But if it is OK for him to add him to every patch, I will do this in future.

Actually I am not intended to wait longer then one or max two weeks, after we get two accepts.