I think you severely underestimate how much effort goes into tackling the computation complexity of those problems as well. Multiple months (at least) went into tackling various exponential blowups in the next trait solver work. That's a typical symptom for NP-hard problems, there's a consistent stream of exponential cases for which you keep adding various fastpaths and caches for various patterns.

Various crates have explicit workarounds for these issues as well, typically using Box to avoid deep types, e.g. axum's `.route()` added it explicitly to avoid this, I believe.

For match exhaustivness, there's currently an active discussion on it again, because it comes up in derives for big enums, and we just landed an optimization that avoids it for some derive macros.

In other ecosystems, I remember a talk about avoiding exponential blowup for various constructs in C++ templates. Typescript even has a guide for how to write types to avoid complexity problems. With libriaries like `ArkType`, people hit these issues a quite a bit.

I won't claim that this is the majority of the compile time work, but it's something that comes up often enough that I think it's pretty ridiculous to say "the worst-case just doesn't occur."