[JesseK]

1) What is your team planning to use?
I want to use LabView itself. I hate dealing with pointers. I'd rather work from an algorithmic level than a nit-picky tit-for-tat variable level. However, I'm not the programming mentor so I don't have final say for what the team will use.

2) What do you think will become the new standard?
In 2 years, LabView. Veterans who stuck to their guns in C/C++ will experience shock and awe when they're stomped by algorithms that would have been hard to program in C, namely things that have to do with the vision system.

3) What will most rookie teams pick next year?
No clue. It seems logical that the previous reply about "whichever has more documentation" is the best prediction.

4) Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?
The FIRST rep at the Q&A said there would be specific libraries for use with an FRC bot. These libraries are being developed by WPI. Other than that, no mention was made about a "custom interface" to the CompactRIO. So it's standard labview with a few bells and whistles that tell the RIO what ports map to what pwms, etc (I think).

5) We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year's kickoff?
Let me consult my Magic 8 Ball... :-p

6) Will there be any limitations to using LabVIEW? Will there be any features that are easily accessibly throught LabVIEW but require complex C? What are the main advantages/disadvantages?
Supposedly we can use a laptop and communicate with the driver's station via the laptop. This will allow us to connect ANY USB joystick or device to the laptop and control the bot. This also implies (though it may later be throttled) that the laptop may serve as an offboard processor for other external scripts. So long as the interface exists and the software can communicate back to the Labview API, the limitations are only limited by your teams' minds. The LabView API can do many many things so long as you properly encode a way to receive the external data (e.g. file inputs...but don't count on real-time direct IP protocol communication...).