The number of name conflicts here has me rather conflicted.
To date, we've been treating the Prelude is a very precious common namespace.
Every name it takes is a significant cost because now every other use of the name, pre-existing or not, has to explicitly _hide_ the import from the Prelude, not just in their library code, but in all the code that uses the library.
By comparison, the Data.List.singleton issue was comparatively clash-free as most uses of a combinator with the same name were already qualified, and we were able to mitigate the remaining issues, by deciding that the module in question was intended to become qualified after a short cycle, so no "global" name is being used up.
Here, we're finding several conflicting combinators, and the cost is significantly higher for each of the existing consumers of that name to work around.
It strikes me that in the end there'd be a lot of churn, as all existing users of conflicting versions of this very short punchy name would have to move to a new name or endure a ton of Prelude hiding clauses all over their code, in both library and consumer code.
This leaves me inclined to a -1.
There are combinators I'm somewhat inclined to push into Prelude after an appropriate referendum, e.g. traverse_ or sequence_ which do a lot of work and are quite conspicuous in their absence, when a worse-for-many-applications but comparable tool is closer to hand, but the slight pain of explicitly importing 'on' seems pretty reasonable given the combination of its somewhat confusing at first idiomatic usage, and the somewhat broadly spread existing name conflicts.
-Edward