@jpearman, that’s funny, because I spent many minutes thinking if I should mention that detail about API calls or not.
On one hand you want to explain behavior of the scheduler as simply as possible (don’t mention).
On another hand you want to explain it as accurate as possible, so people are not surprised (do mention).
You also want to encourage students to think about scheduling explicitly and write vex::task::sleep() in their loops (don’t mention).
But at the same time we want them to learn how real operating systems work, where interrupts could happen at any time (do mention).
By the time I was reading manual pages for vex::thread::priority and refreshing my memory about mutex vs semaphore, I figured out I am overthinking it way too much. 
So, at the end, I just linked to your post. I understand that allowing scheduler to preempt current thread when API function is called makes it easier to implement and helps porting legacy RobotC code where virtual machine could switch tasks at any time.
However, if in the future some of the calls into vex:: classes are going to be implemented as inlineable member variable access methods, then that rule may no longer hold true and it would be easier if students are accustomed to including explicit calls to vex::task::sleep() in their loops.