After thinking it over, I realized that there is another benefit to the current approach. If a major version bump was forced when a library’s peers had a major version bump, then you would lose some information. Right now, you get a complete picture of which APIs have breaking changes by looking at the version number change for the package itself and its dependencies. Perhaps there’s some opportunity to present which peers constraints had major changes in the package docs or with feedback from the CLI.
Either way, I’m glad you brought this topic up @Sebastian, it’s good to make this more clear and explicit, and having this here for reference might help someone avoid confusion in the future.
I think the main issue is not the definition of semantic versioning, but enforcing the same dependency version for different packages. If the dependency is not exposing parts of the conflicting transitive dependency, it might be reasonable to support different direct and indirect versions in general. This is a complicated topic.