As indeed they should. They are operator interface inputs, for the “general case” operator interface where the operator has three +/-1 inputs: forward/reverse, strafe right/left, and rotate CW/CCW about the center of geometry of the wheels. The vehicle motions possible with these three degrees of freedom are a superset of all other motions (such a Ackermann steering or 4-wheel steering).
Now, this is not an operator interface that you’d want to give your driver to use in competition - it’s too difficult to control.
But that’s not the purpose of the spreadsheet. The purpose is to test swerve code, to make sure it is creating the correct wheel speeds and angles… where “correct” in this context means “no translational motion of any wheel parallel to its axis”.
If you have to do significant calculations to describe your intended robot motion in the terms of the spreadsheet (FWD, STR, RCW), I don’t see the utility of the spreadsheet to check your calcs.
It’s OK to disagree about this. But I would make 2 observations:
Even if you have to do significant calculations, those calculations are likely to be quite different from the analysis you originally had to do to create the equations for your code. If you get the same answers for wheel speeds and angles, that’s a pretty good check.
I would argue that it is easier to translate your operator interface commands at a point in time into the equivalent FWD|STR|RCW degrees of freedom than it is to develop the swerve code in the first place.
I don’t want to badger you, but if you have any interest in pursuing this I have a suggestion. Give me a set of operator interface commands for your operator interface, describe what those commands are supposed to make the robot do, and tell me what each wheel speed and angle is calculated by your code at a point in time, given those commands. I will convert that to the associated FWD|STR|RCW and see if we get the same answer.