I've submitted a PR for this. I did discover a use case for boolean evaluation while doing this in the functools.total_ordering helpers. While it's legitimate, it *looks* wrong (the code looks like it didn't consider the possibility of NotImplemented even though it did), and really only applies to the case total_ordering handles on behalf of most folks (implementing one comparator in terms of two others).

The specific case was:

def _le_from_lt(self, other, NotImplemented=NotImplemented):
     'Return a <= b.  Computed by @total_ordering from (a < b) or (a == b).'
     op_result = self.__lt__(other)
     return op_result or self == other

(with a similar implementation for _ge_from_gt). It happens to work because the return value of __lt__ is used directly for both True and NotImplemented cases, with only False delegating to equality. It's not at all clear that that's correct at first glance though, and the fix to avoid the warning is simple, matching the other 10 comparator helpers by explicit checking for NotImplemented via:

    if op_result is NotImplemented:
        return NotImplemented

That's about the strongest case I can find for "legitimate" use of NotImplemented in a boolean context, so I figured I'd point it out explicitly so people knew it existed.

If that makes an eventual TypeError a non-starter, I'd still like that usage to emit a warning (e.g. a RuntimeWarning) simply because the utility of that one little shortcut pales in comparison to the damage done by the *many* misuses that occur.