*sigh* let's not go overboard on what can and can't be
called a "context", either.

So-called "Boolean context" is a useful concept, especially
if you are dealing with overloaded objects. I agree that
it is important to realize that it isn't a "context" in the
same way that "scalar context", "list context", and
"void context" are and that using something in a
"Boolean context" is hard to distinguish from using it
in a scalar context (though it can be done by using
overloading). I'd love to see an enhancement that elevates
"Boolean context" to being a "first class context" (well,
at least "second class" if you don't count "void" as
"first class") by, for example, adding a OPf_WANT_BOOL flag.

"Interpolative context" can also be a valuable concept for
explaining why these are different:

Doing a quick search, I found that keys knows the
difference between scalar and void context so that it can
avoid some work in the latter case. I suspect there are
more than a few other cases. I'm not trying to contradict
you, I just don't want others to overinterpret what you are
saying.

I guess that by "do something different" (in the case of
a user-defined function detecting void context) you are
referring to "side effects" and that you are asserting that
no built-in functions/operators of Perl have different
side effects between scalar and void context. I would
certainly be somewhat surprised to find a case that
violates such an assertion but I wouldn't feel comfortable
making that assertion myself.

I'd take issue with your using "context" to describe
the special way defined works but that would just seem
ornery of me. A similar "context" that I'm finding
increasingly interesting is the "pseudo code block context"
that is given to the first argument of map or grep: