Yes, here’s a little background.
The genesis of the scheduler that VEXcode uses was towards the end of 2015. At that time we thought that RobotC may still run on the V5, I actually did a port of the IQ version of RobotC and had that running. You can see the tiny IQ screen (128x64 pixels) in the bottom corner of this picture.
However, it was decided that we needed to move to a cross platform solution for programming and that the RobotC compiler and VM had reached the end of their useful life, there was just too much technical debt to try and rewrite everything, but that’s a story for another day. The RobotC scheduler had many student friendly features, that is, it was very tolerant of misuse, doing things like treating tasks as functions and calling them over and over. Most conventional embedded schedulers (things like FreeRTOS) are not nearly so tolerant of abuse and can often be difficult to debug. A scheduler was created that was influenced by RobotC but internally was quite different, this is embedded into vexos and was used by Vex Coding Studio and subsequently VEXcode.
The original C++ class we offered was vex::task, this used terminology familiar to RobotC users and is a lightweight class that simply wraps many underlying C API calls. The reason why creating a vex::task with the same callback function just restarts that function is because that’s how RobotC worked. You will see many other class member functions that mimic RobotC, stop(), suspend(), resume() and priority().
But then someone suggested we should be using something closer to std::thread, so we created vex::thread as another lightweight class that wrapped the same underlying C API, oh what fun. We tried to match it’s class member functions to those in std::thread but some just don’t directly correlate. std::thread is also missing some key functionality we wanted. For example, there’s no way to set a thread’s priority from the standard library and no way for one thread to stop another.
So we have two classes that do more or less the same thing and call the same APIs in vexos but have different names.