This also has security implications as in this approach you don't get the fixes to known vulnerabilities. If you update to 1.2.4 as soon as its out, you may be vulnerable to a takeover like this (which happen but are rare), but if you're still running 1.2.3 when 1.2.4 is out, you're definitely vulnerable to all the things that 1.2.4 fixed, and these risks are far more common.

If semantic versioning always behaved as it should be, the default shouldn't be the last thing that worked but rather the major/minor version of the last thing that worked followed by the latest and greatest patch version.

I agree, but you have to start from a known working state at some point - and at that point you are extending trust to that specific set of versions. Anyone who ran `framework create-project` for a framework that included event-stream as a dependency will have downloaded the exploit and then pinned it without knowing.

Stack (https://docs.haskellstack.org/en/stable/README/) for Haskell solves this problem by maintaining sets of curated version numbers that are known to work together.

In theory perhaps, but in practice what actually happens is that your dependencies gradually fall so far out of date that after a couple of years it becomes impossible to upgrade anything at all. Then it becomes impossible to add features and before you know it the whole application is dead end legacy code.