NuGet / Paket Interop on transitive dependencies

Description

Consider the following scenario:

You build a class library with Paket and a direct dependency A (2.0.0)
A itself has a direct dependency on B (1.2.0), however there is also a newer version of B available (1.3.0), which is automatically referenced in the Paket lockfile.
If you package your class library (dotnet pack) the dependencies will only list A as it is the only direct dependency. This "usually works fine" (Even if it is already wrong, see below).

Now assume you work with your class library and add a feature which directly depends on B. As B is already referenced (indirectly through A) you can directly use all of Bs feature. This compiles fine without any changes. Your dependencies in the package will not change.

Now assume a regular NuGet user (or Paket user with strategy: min) uses the package:
-> The resolution will be A (2.0.0) and B (1.2.0), but as your class library is compiled against B (1.3.0) it will fail at runtime.

Repro steps

See above.

Expected behavior

Paket needs to add more direct dependencies if needed (like above) to the final package or fail with a message to add the package as direct dependency.

Actual behavior

Missing direct dependencies.

Known workarounds

Specify B as direct dependency in your class library.

The issue names no files, tests, or entry points. Reproduce the Paket/NuGet packaging scenario with transitive dependency B resolved at 1.3.0 while A requires 1.2.0, then trace dependency generation during dotnet pack. Done means the package declares the needed direct dependency or fails with guidance to declare B directly.