1.) Duplicated dependencies - projects would often download multiple versions of the same dependency, because there was no deduplication happening based on semantic versions.
2.) Disappearing dependencies - under some circumstances, an HTTPS import URL would be unavailable, causing code dependent on these modules to break.
A central package repository could solve for both of these problems. We considered (and very nearly chose) to just use npm, but it introduced functional and UX problems we wanted to solve for users. So we set about building JSR, and did so in a way that wasn't tightly coupled to Deno (JSR didn't need to be - it is useful in the context of any JavaScript runtime).
I’m sorry but that did not come up when designing the system? It’s the whole principle of semver ranges that deno decided to do away with. I cannot believe nobody saw this as a drawback. It’s the first thing I thought when I saw hardcoded versions.
I am imagine most Deno users considered this a weird wart or foot gun, the rest of deno looks interesting.