I'm talking from the point of view of dependency management and code linking, for which it makes a big difference. This isn't about the natural language interp

I'm talking from the point of view of dependency management and code linking, for which it makes a big difference. This isn't about the natural language interpretation. You cannot link against two things that have the same name, that's the point of changing the name. And if you keep the version string as a mechanism to show non-breaking changes, you can safely bump it up. Python packagers mostly followed the advice I mentioned, and they packaged Python 2 and 3 using different package and executable names. If they had used the same name, a bunch of things would have been broken. Imagine a script that is broken by Python 3 which does: #!/usr/bin/env python So when the 2 to 3 migration happened package managers did this: python2 python3 python -> python2 And if you are writing a script that needs Python 3 features you'd do: #!/usr/bin/env python3 Had they not decided to change the name, a lot of things would have been broken. Now the more common case are going to be direct code dependencies for an app. You have a lib called foo, and I depend on it for my application: "dependencies": { "foo": "1.5.8", "bar": "1.3.7" } Now you make breaking changes, you could do: "dependencies": { "foo": "2.0.0", "bar": "1.3.7" } But this forces me to upgrade all at ounce. For example, if bar dependency is also broken by foo 2.0.0, I first have to wait for them to upgrade, etc. If you had released foo2 I could choose to upgrade whenever I want, before bar does, after bar does, or even start by upgrading only half my code to foo2 while the other half is still on foo. "dependencies": { "foo2": "1.0", "bar": "1.3.7" } The downsides of this I've heard is that it might mean less people end up migrating to the new thing, and that it can end up growing the number of dependencies pulled in, since you would pull foo2 and bar and bar would pull foo, for a total of 3. Where-as otherwise you'd wait for bar to use foo2 and then you'd pull foo2 and bar, for a total of 2. And some people say it's good to have this downward pressure to force others to also upgrade to keep everyone aligned on latest versions, might be good for security, or just to keep the pace of progress high. There's also another strategy which is more granular, which is to version the actual code modules or even functions: So maybe your breaking change doesn't break everything but it does break your date module: module foo.v1.date becomes: module foo.v2.date And the dependency is just a feature bump: "foo": "1.1.0" Now your users can choose the V2 module if they prefer it's APIs and features or stay on V1. That one might be harder for the author to maintain over time though. And even more granular is at the function level: function foo-cool() {...} function foo-cool-v2 {...}