This is motivated by Google's shell coding standards and will reduce the
odds of a naming conflict with other functions (which, of course, would
cause terribly odd and difficult-to-find bugs, in both our system and
others').
If this seems like it creates long, overly-verbose function names with no
relief in sight---you're right. I'll have a solution for that in a bit, as a
separate project. ...as a part of my never-ending, growing heap of projects.
This allows the implementation to vary in the number of arguments provided
to the expectation handlers without breaking BC so long as the meanings of
the shifted arguments do not change.
My original prototype was more feature-rich than this, but this formalizes
it and provides self-tests.
It is indeed odd seeing shell code that does not look like shell.