I think I agree that it’s best not to break the SCA paradigm, but at the same time, it’s already broken. For it to be fixed, you’d kind of have to separate Python access from the logic bricks entirely, because currently Python can act as a sensor, controller, and actuator. On the other hand, it’s not like the Python controller’s bad the way it is - it allows sensors to be polled, logic to be executed, and actuators to be activated. There’s nothing wrong with that role of the Python controller, per se. I know people who use Python a lot such as myself tend to really abuse it and end up with an Always sensor and a Python controller running everything about the object, which isn’t really how it was supposed to be used.
A possible solution that probably will catch a lot of flak might be to completely replace the existing logic brick system with the HIVE node system if/when it’s finished. If they’re as easy to use, then they would allow for more functionality and more modularity. For example, we’d be able to compose a MouseLook node of our own using existing sensors, controllers, and actuators, be able to save those nodes to a group and save them out to a library (blend file, for example). We’d also be able to share variables and properties out from one node to another, like BPR seems to want above.
I would imagine this would break any older games, which wouldn’t be too much of a concern since users can just use the old version of Blender until they start a new project. Of course, the sensors, controllers, and actuators that currently exist might easily be transposed to nodes if they haven’t been already. It might not be too difficult at all to make a script to convert logic over to nodes, as well. Each sensor, controller, or actuator can only be attached to one or more other bricks of only one other type in a single direction (S>C>A) - that’s a cake-walk for nodes.
In addition to nodes, adding Python bindings that correspond to all currently available logic brick functions (like the 2D filter actuator or the Radar, Near, and Collision sensors), and providing an ability to override a game object’s logic with a single Python class with pre-determined stub functions would help things out a lot, I think.
I’m grateful to have a MouseLook actuator, nonetheless. Thanks for the merge, Moguri!