I seem to recall reading (though quite some time ago so I may be mistaken), that `yield` was developed for use in robotics as part of the CCR (Concurrency and Coordination Runtime), and it's inclusion in C# 2.0 was to support this.

I read the article, but I failed to understand the problem. What's happening when you pause? Why do you need your functions to pause?

The example robot involves taking a deterministic sequence of actions in a fixed order. The state machine is a line. The article seems to be pretty clear that this code is bad:

    while(drivetrain.getDistanceInches() > -48) 
    {
        drivetrain.arcadeDrive(0.5, 0);
    }

and this code is good:

    while(drivetrain.getDistanceInches() > -48) 
    {
        yield drivetrain.arcadeDrive(0.5, 0);
    }

But pausing doesn't seem to be the functionality that's missing. The first loop will drive backwards until getDistanceInches is at most -48. The second one will also drive backwards until getDistanceInches is at most -48, but it will "pause" intermittently while it drives there. If my robot drives all the way in, I guess, one step (?), what will go wrong?

The tick function is called 50 times per second. Is it constrained to terminate within 0.02 real-time seconds? What if you want to think hard about something?

Only one action can run per robot loop. The first code isn't bad exactly - it just doesn't work for how the robot needs to operate.

Essentially the first code block has the issue mentioned in the article:

    Unfortunately, we can't do this because we need our autonomousPeriodic function to keep ticking. Loops like this will never finish and will cause the robot program to hang. So you can't use loops!

The second code block yields every command back to the robot until the robot is ready for the next command - it's not actually the same as the article code but I think it's better design to return a command to the robot than to run a mutable operation in the brain code, it makes it clearer to the user that it is necessary to let the robot do the work.

The article's point is there are many ways to write the state machine code that makes this possible - and the coroutine approach is the easiest for students to understand. It's also quite clean and practical for real world use too.

The problem is more in how you combine that with something else. Consider, you have two "routines", one for "pick up ammo and take a shot" and one for "evade attack". Without a "yield", then your recovery time after an action is the longest chain of actions you have encoded. With the yield, it is the longest of a particular "command" that you have.

Dots instead of colons ?

Yes good catch; oversight from posting on mobile. I've fixed it up