Perhaps from here we can talk about things that should and shouldn't be separate threads. For example, is there any value in putting different mechanisms on different threads or does that not matter? Vision is the obvious choice for a new thread, yet then where does the thread safety come into play when translating the results of vision to what the robot actually does?
For example, in teleop 2013 this example logic would simply allow vision to override what the driver did without a state, supposing that vision was processed later in the loop than control inputs. Yet in 2015 using threads, the output ports would be set to two different values based upon two separate PID targets. Neither PID target would ever be reached - what is the behavior of the robot?
Code:
Thread A: Button Input -> Input Processing -> Use PID to go to preset since button is held
Thread B: Vision Processing -> Use PID to go to vision angle until operator cancels
Sure, once we discover all of these errant scenarios we can prevent them via operator behavior modification, but until then I'm sure we'd like to not smoke the motors.