It so happens that I have some experience with CrystalSpace, which I’ve used before moving to Panda (and staying, which probably says much about both).
On a side note, I don’t see any point in using Blender as a game engine, especially for a serious project, from the game engine feature set standpoint. But maybe that’s just bias because I think of Blender as a graphics/level editor rather than anything else. One thing’s for sure – it’s not the most scalable and not the most efficient solution.
Going back to Panda and CrystalSpace. I’ve used CrystalSpace for quite some time. I’ve started a project there, which I rewrote to Panda and have been developing it here since.
In general, I see Panda as more reliable and stable. Both engines have fantastic and helpful communities, but Panda has a more stable release cycle, as well as faster response to bug reports. Also, I’ve found Panda to be much better documented, especially if one wants to use Python.
Although Python can be used with CrystalSpace (and CEL, which is what actually makes CS, the rendering engine, a game engine) it felt rather rough. Unlike Panda, which was designed from the ground up to be used with Python, CS/CEL was initially meant to be operated using a combination of C++ and XML. This leads to using Python in much less “pythonic” ways than it should be used, because the python-side API is much less mature.
So if you want to use Python (and I see no reason why you wouldn’t), then Panda is the obvious route.
As far as physics is concerned, both engines support the ODE physics engine out of the box. For more robust physics solutions, Panda allows easy integration with PhysX (but it’s incomplete) while CrystalSpace support Bullet out of the box. I have no idea about the state of Bullet integration into CS, but I remember the documentation was lacking in this regard. Dunno if it still is.
Panda has a much better mechanics for in-game animations (for so-called “scripted sequences”, like in-engine cut-scenes and stuff). It’s the Interval/Sequence/Parallel system and I found it to be extremely easy to use and incredibly flexible. Dunno, maybe CrystalSpace had something similar, but if it did, I never managed to find it (documentation?) and needed to write 10 lines to do what Panda does with 1.
As far as “user control” (and I hope I got that one right), there are no constraints here. In neither engine. You, as the programmer, decide what the player’s input controls, not the engine. In fact, there’s even no such concept as “the player/the user” internally. You can attach the camera and input to anything and reattach it on the run as needed, there are no limits.
Oh, one more thing. With CrystalSpace you will probably need to build the engine from source. While there are binaries (as far as I can see) for CELStart, which is all you need to code a game in CS/CEL, the Panda’s support in this regard is unbeatable. Not only are there windows, linux (in distro-specific packages) and mac binaries for stable versions, but there are development version builds as well (which is more important than you might think).
So, to sum it all up, in general, I find Panda to be a much more complete and developer-friendly engine. That’s just what I can say from my experience with both.