Additional changes:
py_repr doesn't need to be virtual - this is not going to be inherited from.
whitespace fixes for KX_Scene

In D1156#20753, @Sybren A. Stüvel (sybren) wrote:

I'm missing motivation for this change. Who would use this, and in what kind of situation? How will this change impact performance? As far as I see, all messages (so bodies + headers) are copied, even when a game doesn't use this new feature.

Concerning the use case, I recently desired this for an addon for the BGE.

It adds an interface for networking through the message system. It does so by modifying subject fields of the sensors and actuators of specific objects to include a unique identifier for that object (network id). These messages must be picked up by a global message listener, in order to be handled appropriately.

With the functionality provided by the main custom property of bpy.types.Scene, it is possible to completely remove any non-user code / logic bricks from the logic editor, allowing the addon to drop-in and without having to worry about ensuring the listener object is always there, on the current layer and not deleted.

Given the relative lack of messages being sent in a game at any one time, and the relatively slight performance cost in copying subjects/values I made the decision that it wouldn't be of any bother, though I could move to a cache based design if necessary.

In D1156#20817, @Angus Hollands (agoose77) wrote:

Given the relative lack of messages being sent in a game at any one time

How do you know this? It seems like quite a big assumption.

The C++ side uses an OO design (NG_NetworkMessage), but the Python side uses a separate-list-per-property design. As this generally makes for a hard to maintain/extend interface, I'm not a big fan.

This is a nearly direct copy of the message sensor. However, it might be best to support a python proxy for messages and also expose that to the PyAPI, but it adds weight to the class. Ill take a look later.