Okay, I have to admit that in this particular instance it's not quite my intuition which causes the pain. Or rather, it's a different kind of intuition, which I have acquired from Haskell in particular – "I don't have to be particularly careful about minor refactorings, because if I change the type of one thing, the compiler will tell me what other things I have to change if I want to preserve the logic of my code". The behavior of 'length' breaks this intuition because "I'll just pass a tuple here instead of whatever I used before" stops being a (relatively) safe refactoring.

(I'm saying "relatively" because of the existence of other extremely polymorphic things – e.g. 'Aeson.encode'. Luckily, they're much less common than 'length'.)

(An example of a scenario which more closely fits what I originally had in mind: Set.size is O(1), but HashSet.size is O(n) – this one was pretty fun to hunt down when we found that our code was unexpectedly slow. Unfortunately, I can not adequately expand the intuition behind my initial judgment of "HashSet.size is surely fast", because it's hard to do at 4am.)

The pain is pretty easy to demonstrate: I had to waste a day recreating the Foldable/Traversable hierarchy in a custom prelude to ensure that nobody in my team would be bitten by a refactoring. It wasn't *that* painful, sure – but it's somewhat scary to think that there might be dozens of other refactor-unfriendly functions lurking in libraries we're using (and one day they will come to bite us).