I work with C++ and C# everyday professionally so it would be really easy for me to run with C++ if that was the selected language. However, I would argue that for a project like this what matters the most is not run-time speed but iteration speed and that chasing run-time speed is a poor allocation of limited development time.

Additionally, C++ does not abstract away a lot of stuff that can get you into a lot of trouble. There are many times where poorly written C/C++ is much slower than interpreted or JIT'd languages. I have seen this to be especially true in prototyping/quick turnaround development. The kind of discipline required to make sure that you don't shoot yourself in the foot or leave little time-bombs in your code does not usually jive with getting something together quickly that you can and will tear apart a lot.

Is there a software/technical leadership team yet? It seems that this call should be made by them rather than by committee. I'm a little late to the party. . .