2nd/3rd Level Dependency (fsharp.core)

I'm not sure if this is the right place for this, but seeking help/advice here 1st 🙂

I have a weird issue with fsharp.core/Paket/msbuild, I don't know where in the chain the issue is though.

I consume https://www.nuget.org/packages/Sproc.Lock/ which needs fsharp.core 4.0.0.1 or higher in a repo with latest fsharp.core (4.2.1).

Assembly a takes reference (in dependencies) to sproc lock (but not fsharp) and Paket puts binding redirect and uses correct version of fsharp in the bin according to Paket.lock. Great so far!

Assembly b project references assembly a, it does not have sproc.lock or fsharp.core in the dependencies file.
This also gets the binding redirect (through a second level dependency). Again, so far so good.

However, when built you get the 4.0.0.1 version of fsharp in the bin.
This is located from the machine install of fsharp, rather than taking the version out of assembly a.

I can "fix" this by adding fsharp.core (or sproc.lock) to assembly b dependencies file, but where does that stop...if assembly c takes reference to assembly b, it also needs these references?!?

I'm essentially looking for advice or clarification if this is a big or expected behaviour.
I can try and setup an example public repo to show this behaviour of that helps.

Start by reproducing the dependency chain described for assemblies A, B, and C, using Paket.lock and each project's dependencies file. Compare the binding redirects and copied FSharp.Core versions, including the machine-installed 4.0.0.1 version. Done means determining whether the transitive dependency behavior is expected and documenting or fixing the result.