Yes, I think there's a lot of history here that obscures the picture.

We have mechanisms in Python to allow 3rd party objects to be interpreted as floats (via __float__) or as integers (via __index__). 

So np.int64 (for example) doesn't subclass int (on Python 3), but is usable as an integer almost everywhere that that makes sense because it defines __index__ (and __int__, but it's __index__ that really matters here).

If you're writing something bool-like in a 3rd party library, and you want it to be duck-typeable as a boolean in calls that expect a boolean flag, what special method should you implement? It seems clear to me that the answer should be __bool__, but the current error message appears to be telling the NumPy folks that if they want this to work then np.bool_ should (continue to) implement __index__. That feels odd to me: it's a completely legitimate and sensible choice on NumPy's part to decide that np.bool_ objects *aren't* integers, and shouldn't implement __index__.

The NumPy bug report demonstrates that the concern isn't hypothetical: np.bool_ really *is* a boolean type, and it's easy and natural for a NumPy user to end up passing an np.bool_ instance instead of a bool instance where a flag is expected, and then rather surprising when that doesn't work as expected. I've run into this myself on occasion (turns out that PyQt doesn't like np.bool_ objects either, but that's another story).

The one disadvantage that I can see of allowing arbitrary objects to be used as flags is the potential for surprising failure modes when a function is accidentally misused. For example, it could be surprising if something like:

> "aaaXbbbXccc".splitlines("X")

returned ["aaaXbbbXccc"] instead of raising as it currently does. But many flags are keyword-only, which would make it harder to run into this sort of thing accidentally.
 
In short, I think this particular case _is_ a bug that should be fixed.