I don't find ordering of patterns appealing, I find it scary! I order my patterns according to the semantics I desire, and then additionally by what looks pretty. I'd like it if whatever cleverness GHC can work is used rather than requiring me to think. If the order of patterns is to become important, it has to be with an explicit "look, I know something you don't" pragma rather than by default.
No need to be scared! As I mentioned, Haskell already specifies pattern match order left-to-right, top-to-bottom, so the declarative semantics wouldn't change one bit. I'm just suggesting to use the existing specification, in order to make the generated branching code somewhat more predictable. We don't know yet whether this would make a worthwhile difference, but if it would, then being able to express performance constraints without affecting the declarative semantics might seem more important than aesthetical considerations. Not to mention that the alternative would be to spoil your pretty code with pragmas!-)
As an example, I suspect that the "hot-path" on most list pattern matches is in the (:) case. I don't want to ever teach a user that (:) comes before [] because ... long spiel about branch prediction ...
It is the other way round: without branch prediction, the order of tests did matter, branch prediction hardware can figure out many things without help, thereby making the order of tests in the code less important - but that can be defeated. http://en.wikipedia.org/wiki/Branch_prediction As long as you're sure your students don't need to care about performance, there is no need for you to teach them about it. But if their ByteStrings aren't as fast as they need to be, they will very much want to know why (the example in #849 was from ByteString). Unless they just give up.
Controlling branch prediction will only ever be a niche activity, so the defaults should reflect that.
My impression is that branch prediction hardware is (usually) designed for users with full control over generated code (eg, the Intel compiler manuals seem to advise loop unrolling to match and complement the branch prediction hardware exactly). If you don't have that kind of control, and generate code as if there were no hardware-level optimizations, the resulting mismatch will manifest in hard-to-predict variations in performance, making it difficult to see how much or why speed is lost. No fun. Claus