It sounds to me like one of those perfect is the enemy of the good situations.
I've seen things like this with regard to development and compromise:
The 90% solution costs $X + time
The 95% solution costs 2*$X + 2*time
The 98% solution costs 2*2*$X + 2*2*time
and so on...
Most of the time, motors intended for EV use have some form of position feedback. I think that it would be a good place to start. - Use the one on thingstodo's motor.. In addition, if a single speed gearbox is used, the vehicle speed can be directly derived from the motor's position feedback. That saves a sensor down the line.
The cheapest easiest solution I've always seen in app notes is the one using 3 hall-effect sensors. I think that if 1 sensor could be installed, then it wouldn't be that much more difficult to install 3 and have the option of 3 hall-effect sensor code.
Here is where having the code split up for different types of position feedback would give an excellent opportunity for both the final user and software/hardware development.
The sensorless code Paul is working on could also be very useful for "filling the gaps" of information when less accurate encoders or hall-effect sensors are used.
It seems Paul has a very full plate right now. For my bit, I'm going to attempt splitting up the sensorless.c code into functions. I will use all the original variables, comments, programming style, etc. Paul - if this seems helpful, let me know. Also - if you have suggestions, please let me know.
E*clipse