> && is always strict in its first argument.
Well, if you need to evaluate (&&) you will necessarily need to evaluate its first argument. Much like (||). This behaviour works similar in many other languages.
On the other hand, the first argument passed to (&&) will never be evaluated until needed, so it is still lazy as expected. A good way to test this behaviour is to try this in GHCI:
let a = (length [1..] == 3) && False
Simply declaring a won't enter in an endless loop, but asking to show a will indeed loop endlessly.
Likewise, it is hard to understand how you expect pattern matching to not look at an expression's value when deciding which branch of the code it should use next.
> My position is still that lazy-by-default is a really bad evaluation policy and that consequently, Haskell is a dead end in language evolution.
Yeah, I have understood that you have an opinion. Nevermind that people run it in production without issues.