Executive summary:

- let's change the behaviour of mode to return a single mode rather than raise an exception if there are multimodes;
- and let's do it without a depreciation period.


Further comments in no particular order:

I agree that in practice the current implementation of mode has turned out to be quite awkward.

Unfortunately I feel that just chosing one mode and returning it as "the" mode is statistically dubious (despite it being commonplace!). I've checked with some statisticians, or at least people who claim to be statisticians on the Internet, and they agree.

(The usual advice from statisticians is to always plot your data before talking about the mode or modes, as even local maxima can be meaningful.)

Nevertheless, Raymond's use-case of the nearest neighbor algorithm is persuasive. We should change the mode function to return one of the modes.

Which one? Again, people I've spoken to suggest that there's no statistical basis to picking any specific one (first found, last found, smallest, largest). I'm unhappy about documenting which mode is returned, as I expect it will be an implementation detail that could change in the future.

Raymond, are you happy to leave the specific detail of which mode is returned unspecified? Or do you have an argument for why we should specify it, and can do so without limiting future implementations?

I too strongly prefer a separate multimode function over a flag to the mode function.

As for backwards-compatibility, I've asked around trying to find anyone who claims that changing the behaviour would break their code. I haven't found anyone. I guess that means that unless any of the other core devs object, I'm happy to go with Raymond's recommendation to just change the behaviour without a depreciation period.