processing a relocation erases requested version range

While fixing MNG-2861, I came across a weird scenario where the contents of the relocation can affect what happens. In 2861, the relocation did not specify a version, only a group id. However, if a version is specified, in MavenMetadataSource: 164 the versionRange is reset to the contents of the relocation.getVersion(). This effectively tosses out the requested range information. We only get here after selecting the version that has been relocated, but now we have a recommended version, which can cause a different version to be selected. See the two sample projects in MNG-2861 to see how the handling is different. (brett's version has the version in the relocation and thus expresses the behavior described here)

The fix is simple, change the line to:
if ( relocation.getVersion() != null )

however, I'm not certain what the ramifications of this are. The potential exists for having selected a version that no longer matches the requested version range. Say the version range was [1.0,2.0] and 2.0 was relocated to 3.0. The fix to 2861 involves reloading the available versions from the relocated artifact. This means that there is no not an artifact to match 1.0-2.0 and who knows what's going to happen.

I'm choosing to document this and not fix it for now due to the risk of instability. A search of open issues didn't result in anyone experiencing trouble with this.