If we have dependencies defined like this:

    <Dependency Name="Microsoft.DotNet.Arcade.Sdk" Version="6.0.0-beta.21105.5">
      <SourceBuild RepoName="arcade" ManagedOnly="true" />
    </Dependency>
    <Dependency Name="Microsoft.DotNet.ApiCompat" Version="6.0.0-beta.21105.5">
      <SourceBuild RepoName="arcade" ManagedOnly="true" />
    </Dependency>

There's a potential that the versions will diverge if one of the package names change, one of them is manually updated. And actually divergence can be intentional, for targeting packs:

    <Dependency Name="Microsoft.NETCore.App.Ref" Version="5.0.0" CoherentParentDependency="Microsoft.NET.Sdk">
      <SourceBuild RepoName="runtime" ManagedOnly="false" />
    </Dependency>
    <Dependency Name="Microsoft.NETCore.App.Runtime.win-x64" Version="5.0.2" CoherentParentDependency="Microsoft.NET.Sdk">
      <SourceBuild RepoName="runtime" ManagedOnly="false" />
    </Dependency>

Once they diverge, I think that the tooling will bring down two versions of the intermediate nupkg, which doesn't represent what source-build can actually do in a tarball.

Picking a single dependency node is how we decide what the coherent graph of repos should be.

I think the tooling should detect when a repo is set up this way, and fail pre-emptively.

For #2034, we'll probably need to restore multiple intermediate nupkgs from a single upstream, but all of them should come from a single dependency node.