I would contend that this is an issue with namespace collision / poor namespace management than it is an issue with semver.

For example when I have a REST API endpoint I always prefix it with /<module>/<major-version>/ - would never expect to host both old and new versions on the same base URL

Well they're wrong and so is their language of choice. Any language that pollutes the global namespace when you import a lib did it wrong. For all of JS's faults, they nearly got this one right.

Also, even in JS this is still a problem when you really do want all packages to share the same version of the lib, regardless if you're able to import multiple. Sometimes you just don't want multiple instances.

Npm and yarn offer a solution for that too, by forcing a certain version resolution but that then you're on your own if it isn't compatible.

Even if coexistence of multiple library versions is supported, there are scenarios where things break.

For example, the "libc apocalypse" situation in Rust https://github.com/rust-lang/libc/issues/547

Here after the "libc" module released a major version, the definition for the `void` C type in two versions of the lib are considered by the compiler as two different types, resulting in breakages everywhere around the library ecosystem.

There are also scenarios for dynamic languages / runtime errors.

My main problem with the current SemVer spec, is that it does not mention the multiple lib versions problem, and promises the dependency hell issues can be avoided simply by updating major version number. Thus encouraging to break backward compatibility freely.

Also note, it's not the case that SemVer is intended only for languages supporting multiple library versions in one app. SemVer is a product of Ruby community, and Ruby has a global namespace for classes and unable to have several versions of a lib simultaneously.

In 2000s Ruby library authors were breaking compatibility left and right, neglecting elementary compatibility practices. If you were working on an application, practically every time when you update dependencies, the application would break.

So (in 2011 ?) they came out with this "manifesto" (Why such a big name? This scheme of versioning was well established in linkers and sonames of all Unix-like systems for decades - it goes back to at least 1987 paper "Shared Libraries in SunOS").

It's a good thing SemVer acknowledged finally that compatibility is a serious matter. Only that it's better to discourage compatibility breakages. An in cases when it's really needed (I agree such cases exists), there are things to take care of in addition to simply increasing major version num.