There's a difference between build-time dependencies and runtime-dependencies. And as a second layer of confusion there is a difference between bundle/project versions and package versions.
Let's first deal with the build time. At build time you specify the dependencies via maven coordinates. For example you specify that you want the uber-jar artifact in version 6.5.5. Packed in these uber.jar are API definitions at a certain state. These API definitions also contain version information at java package level. During the build process the bnd-maven-plugin (or the maven-bundle-plugin, depends a bit on the version of your archetype, but basically they are doing pretty much the same) extracts these package informations of the APIs you are using and writes these version information into the MANIFEST.MF (which is then part of the bundle).
When you now deploy this bundle into AEM (or any other OSGI container), the runtime reads these dependency information and tries to resolve them; for that it scans the packages exported by other bundles and checks if there is a matching package export within the correct version range. If such a package is found, everything's fine and the dependency is resolved. If you have any package which cannot be resolved, the bundle won't get active.
So, to answer your question: On runtime any maven or bundle version numbers are irrelevant. Only the package versions are relevant. In your case the package version has not been updated (it's always 1.0), so it doesn't matter what bundle version your bundle B has, the current version is bound because the dependency is still resolved. At https://bnd.bndtools.org/chapters/170-versioning.html there is some description how you can define the version number for your packages. If you use the bnd-baseline-maven-plugin it can tell you if you should really bump a version number.
So, when are versions relevant at all? Versions are only relevant, when they are describing an API (that means, we are talking about java interfaces in the first place). You can implement the evolution of an API (most notably: Incompatible changes) via such versions, so you can express: As a consumer I need at least version 2.1 of the API; if your OSGI container does provide this API only in version 1.9, your bundle will not get active and you can spot that problem immediately. In most cases it makes sense to have both API and implementation in the same bundle, so this situation is very intuitive, and API and implementation will always match.
But of course there are other situations, where it _could_ make sense to split implementation and API into separate bundles. But these are quite rare and make only sense where there is a benefit in decoupling them (mostly from a maintenance point of view).
Some final remark to the runtime aspect: Technically OSGI allows you to have a same java package being present in 2 different versions. Right now the AEM support for this scenario is not existent (I don't think it's tested, although the OSGI runtime should support it), so it's better to have a java package only in 1 version exported. If you need to have a newer/older version of a package provided by AEM (which is of course not part of the AEM surface, but rather some 3rd-party lib), you can embed that library, so your dependencies are not resolved by OSGI by using references to other packages, but instead to libraries residing in your own bundle.
Hope that helps,
Jörg
