+1 from me
We export `on` from `relude` by default and didn't have any problems so far:
I believe that this proposal hits the same wall like all other proposals regarding changes to the standard library — it's not clear, what are Prelude goals. Should it be minimal and provide only fundamental things, or should it enforce commonly used idioms? I think that the `on` function from this proposal is the most widely used version of any other function with the same name. When I see `on` in the code, I first expect the version from `base`, not from some external library with a different type. Implementing your own `on` in your library and forcing users to use it makes code hard to read and reason about. Especially when people are using implicit imports — good luck figuring out which one `on` is used! I believe that if `on` was already imported by `Prelude`, fewer people would introduce identifiers with this name. Which means that exporting `on` from `Prelude` is an excellent thing to do if `Prelude` wants to force idiomatic usage of this function.