Why isn't (20 >) . length . take 10 === const True

take 10 has to determine if its argument is a [] or (:) value.

const True does not.

length is strict, in that it has to iterate over its entire argument. Composition doesn't mean that it only has to iterate over enough values to get a number big enough to falsify (20 >).

After all, length $ take 10 $ whatever can't be other than <= 10 [...]

Is not correct in Haskell. The length function may in general crash or go into an infinite loop. In both cases it would not give a valid integer as result, and that lack of valid integer can not be compared to 10. In general, evaluating an arbitrary expression may result in either a value for example (1::Int) or bottom. Where bottom generalizes over all reasons why the expression may not result in a value.

The expression 20 < length $ take 10 $ whatever, therefore must evaluate to either True or bottom and for the compiler False is even an option. As you have seen both True and bottom are valid results. By contrast, const True whatever is different as it always evaluates in True without evaluating whatever.

The behaviour you're seeing is much more to do with length and > than with take. length has to return a specific number, and (20 >) can only be run when supplied with a specific number. What number do you imagine is being processed in the middle of your pipeline?

You acknowledge that length $ take 10 $ fix error is (and should be) bottom. There is not even one single element of the list fix error that can be looked at before encountering an error so there is no number that could be returned that is an accurate measure of the list's length. (It might be tempting to say its length could be zero as there aren't any elements there, but that would imply that fix error is equal to [], which isn't true either. Really asking for its length is simply an error.)

However, you now want to feed that bottom value into (20 >) and expect the result True. But bottoms are interchangeable, so this would require that 20 > undefined is also True. And indeed, it would require (20 >) $ length $ take 50 $ fix error to also be True.

Your intuition seems to be that length . take 10 is not capable of returning a value greater than 10, so (20 >) . length . take 10 should be const True, and thus shouldn't need to examine its input. You've obviously noticed that that isn't accurate for current Haskell, but I don't think it would be desirable behaviour anyway. My intuition is that (20 >) needs a specific input number that is less than 20 in order to return True; a vague notion that its input can't be a larger number isn't good enough. If its input is an error (any error) then neither True nor False is an accurate return value.

Note that length $ take 0 $ fix error is a very different case. take is defined equivalently to this:

take n _
  | n <= 0  = []
take _ [] = []
take n (x:xs) = x : take (n - 1) xs

It checks whether the number of elements to be taken is zero (or less) before it examines any of the list, and if so it can return a specific concrete list [] without examining the input list (and therefore without triggering any errors from fix error or undefined). Then length can measure [] and return 0, which is less than 20.

Similarly, length $ take 10 $ [fix error] works because take 10 can return a list of length one without examining any of the elements inside the list (and thus without triggering the error), and length can measure that list and return 1, which is less than 20.

Both of these cases never actually require a specific value for any property that is undefined, but your original case does (the length of an error). It's not to do with "ensuring we're working on [a]", just whether your answer depends on a value that is undefined.

If you wanted, you could define an "unsafe" take-like function that is guaranteed to return exactly the specified number of elements.

tack :: Natural -> [a] -> [a]
tack 0 _ = []
tack n ~(x:xs) = x : tack (n-1) xs
-- Alternatively,
tack n xs = head xs : tack (n-1) (tail xs)

tack 10 undefined will now be the list replicate 10 undefined, so there's no difficulty calculating that it's less than 20.

Going back to your question, the list take 10 undefined has no length, in any sense, so we can't say it's less than 20. Even using lazy natural numbers won't help.

data Nat = Z | S Nat deriving (Eq, Ord)
instance Num Nat where
  fromInteger 0 = Z
  fromInteger n = S (fromInteger (n - 1))
  ...

length :: [a] -> Nat
length = foldr S Z

take :: Nat -> [a] -> [a]
take (S n) (x : xs) = x : take n xs
take _ _ = []

Now we will have length (take 10) (() : undefined) >= 1 === True, but we still can't say it's less than 20, because "it's at least one" is all the information that exists about that length.