I'd personally love to see C/C++ as the core language with an OBJC wrapper, since that would allow the engine to easily port to other platforms, and make keeping those platforms in sync much easier, but it has significant downsides as well. From the users point of view, it would mostly look exactly the same, since the OBJC wrapper would just pass through to the C backend. Users could even ignore the OBJC wrapper and write to the C++ API if they wanted too.
I rarely modify the cocos source unless I am adding new capabilities to the engine itself, so I think for most people this would keep the interface roughly the same.
That said, it does add quite a bit of boilerplate to the OBJC version. This boilerplate is only really worth it in the context of making cocos easier to synchronize across platforms. I think everyone here is bought into the basic design of Cocos2d, the question is how much does cross platform matter to most people, now or in the future?
Doing something like this would also lead to a lot of hard questions about how we should handle the API's on the platform level. Cocos currently wraps Apple's touch API's for us, would this lead to us wanting a lot more APIs wrapped? What about devices with lesser capabilities? Would this lead to providing common denominator APIs that work at the lowest level? All of this would pull resources away from other features, make changes take longer, and increase complexity and code size. That may be worth it if portability is a major concern to the community though..
