What is the expected resolution behaviour for mixed ProjectReferences and PackageReferences

Details about Problem

NuGet product used: NuGet.exe

NuGet version 4.5.1.4879

OS version: win10 v1803 17134.706

We're in the process of migrating lots of source deps to binary deps (i.e. ProjectReferences to PackageReferences) in our codebase at the moment, and are finding some issues with the version resolution behaviour when there are PackageReferences and ProjectReferences to the same assembly in a project's dependency tree (this is obviously not a state we're particularly keen on being in, but it's inevitable it will exist at least for a while during the transition).

Is the expected behaviour for NuGet dependency resolution in this case documented anywhere? (It is not the same behaviour as for multiple PackageReferences to the same assembly as documented at https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution).

Detailed repro steps so we can see the same problem

Some examples of behaviours I have seen in different cases:

Case 1 - Direct references

(probably not a case we have to worry about, but for completeness):

A -[PackageReference]-> B (version x)
A -[ProjectReference]-> B (version y)

Assembly A's project.assets.json always contains assembly B at version y, regardless of whether it is higher or lower than version x. Builds always succeed

Case 2 - Transitive cousin references

A -[PackageReference]-> B (version x) -[PackageReference]-> C (version y)
A -[ProjectReference]-> D (version z) -[ProjectReference]-> C (version w)

Assembly A's project.assets.json always contains assembly C at version w, regardless of whether it is higher or lower than version y. Builds succeed if and only if w >= y. If w < y the error on build is:

A.csproj : error NU1107: Version conflict detected for C. Install/reference C directly to project A
 to resolve this issue.
A -> D -> C
A -> B x -> C (>= y)

(The suggested resolution does work)

Case 3 Transitive non-cousin references

A -[PackageReference]-> B (version x) -[PackageReference]-> C (version y)
A -[ProjectReference]-> D (version z) -[ProjectReference]-> E (version v) -[ProjectReference]-> C (version w)

Exactly the same behaviour as Case 2 (i.e. proximity to the application doesn't change the behaviour like it does when we have 2 PackageReferences to the same assembly in the tree).

Is the short answer to a long question that the AssemblyVersion of an assembly referenced via a chain of ProjectReferences is always the version that gets used, regardless of how far down the tree that dependency appears?