The problem with this is that it is not practical. One example I can think of on the spot is an old tool written to support Windows 7, a bridge version supporting win 7-10 and a new version supporting only 10. Most industries do not move at the same pace (We have some projects that can only run on Windows 95). So some security updates to the bridge version adn the new version are made simultaneosly and corresponding update to their version numbers.

Another example is python 2 and python 3, where python 2 was getting updates form 5+ years after python 3 released.

Python 2 and Python 3 are different languages that get installed side by side.

Two completely independently developed C compilers, or independent implementations of Common Lisp are much more compatible with each other than are Python 2 and Python 3.

They could as well have different names (think Perl vs. Rakudo).

Racket is more compatible with Scheme than Python 3 is with Python 2, yet has a different name, for good reasons.

Both Python 2 and Python 3 could respectively use a simple versioning numbering scheme. Python 3 version 1, version 2, version 3, ...

The problem was not with a random someone wanting to make a change to version 1, it was with the project wanting to make a change to version 1. That is not a downstream problem.