This functionality is not disallowed, it is just not very common as a result of the way most libraries numbering work and because of the inconvenience of package name changes.
If the use a dotted version number scheme X.Y.Z. The "micro" version Z often changes on bugfixes, the "minor" number Y changes on backward compatible changes and the "major" version number X has to change on API changes (and sometimes does on major extra functionality).
There should never be a reason that you do not want to have the latest bugs fixed, and backward compatible changes should not break your software either.
If the library is developed that way you should always be able to replace X.Y.Z by X.(Y+m).(Z+n). for any given m and n. I.e. you should always be able to replace your library with the latest in the same major number series.
And if the library developers are careful and the next major number is compatible (e.g. by the announcement to deprecate things, but not remove them yet) you can even use the next major number.
For package developers this means they can use the name with just one, or even no number name to give you the latest version by just updating the package. If they ship a library in a package abc2
then they have to go through hoops to move their own software that relied on abc2
to upgrade to use abc3
, sometimes with transition packages. It is more convenient to leave out the major version number from a library if that works for most depending packages. So even if both abc2
and abc3
should be available at some point available in a distribution, abc3
is often called abc
(just like abc2
was called when there was not abc3
yet), and as soon as no packages depend on abc2
within the distribution it becomes possible to drop abc2
altogether.
The numbering scheme is not uniformly followed, but I can only imagine that with the advent of the internet disseminating information on how to use such a scheme, and the pressure from library users (including distribution developers) to make important things like backwards compatibility clear without having to read through a CHANGES file included in the library, have contributed that this has become more common.
One counter example, but not of a library is the python intpreter, which is not compatible on its shared objects and pickling format on a minor number change. Therefore you will see packages for python (the latest in the 2.7 series), and python3 (the latest in currently the python3.4 series) as well as explicit packages for python 2.6 (not getting less common) as well as python 3.3.