This whole area was discussed quite a bit in the OSGi R4 standards work. We had to decide whether to give special meaning to specification-version or whether to treat it as a synonym for version.
In the end we decided to treat it as a synonym to avoid the confusion of having an interface whose specification-version had not changed but whose implementation version had changed and trying to define client compatibility policies based on two version numbers.
The way to approach this area is to bear in mind that each interface belongs to a package and every exported package has a version number. This version number should be considered to be the version of the interface. This is completely separate from the bundle versions of the bundles exporting and implementing the interface.
(There is a subtlety which can help in some edge cases, but which you should ignore as a general policy. On rare occasions where clients of an interface have adopted a strict version range policy (e.g. using ranges like [1.1,1.1]) and a new version of the interface is available which is strictly backward compatible, then it is possible to export the same package multiple times with distinct version numbers from a given bundle. This can enable "strict" clients to wire to the new version (via the older version export).)
With that in mind, please see if that helps the scenario you have in mind and post back here if not.