[pydry]

>It also kind of cemented for me that weird edge cases don't actually matter in practice

I had the exact opposite impression. Indeed, this stuff is the cause of so much that gets attributed to something else (e.g. JavaScript framework churn being attributed to culture).

The problems caused by these issues compound as you work your way up the stack.

[jan_Inkepa]

I think I get where you're coming from, that weird low-level behaviour could result in the things you build on top being unstable (I have been able to avoid the employment of the big javascript frameworks/systems, so have not had to suffer a lot of technology churn), or harder to build on top of [see my reply to another comment], but OTOH abstracting away weirdness one of the fundamental functions of engineering? And why would, say, undesirable array semantics result in framework churn on top? Because people are trying to 'fix'/'mitigate' the behaviour but can't settle on a single solution?

[aflag]

Often times it's because there is no good solution. That is, you can't really fix the problem without being overly strict and making common use cases impossible or awkward to use. So you settle for something that usually works for most people. Bad designs have a tendency of creeping up.

The thing about things designed with bad edge cases is that they can have dire consequences for some people, but as long as it works for most people, they stick around. Forever causing pain.