We make the changes to foundation (Foundation-A) and push them out to the nuget feed as an unstable package.

Here's where your problem begins... Don't do that.

Any changes to Foundation v1.0 should inherently be valuable to all consumers of Foundation, otherwise it doesn't belong in Foundation. So, when creating the nuget package, do it as an official, stable version of Foundation (i.e. v1.1), or don't do it at all.

Project B should build its Foundation enhancements as it normally would, but (in good source management fashion) should merge in the trunk changes (v1.1) before pushing a stable Foundation (v1.2) to nuget.

Other projects which can use the Foundation enhancements can upgrade their nuget references when appropriate, or stick with the older versions if they need to.

I agree with @Giedrius; this seems to me to be more of a source control/branching issue in the sense that if the branching/merging of Foundation is handled properly, the package management issues become moot.

We make the changes to foundation (Foundation-A) and push them out to the nuget feed as an unstable package.

Here's where your problem begins... Don't do that.

Any changes to Foundation v1.0 should inherently be valuable to all consumers of Foundation, otherwise it doesn't belong in Foundation. So, when creating the nuget package, do it as an official, stable version of Foundation (i.e. v1.1), or don't do it at all.

Project B should build its Foundation enhancements as it normally would, but (in good source management fashion) should merge in the trunk changes (v1.1) before pushing a stable Foundation (v1.2) to nuget.

Other projects which can use the Foundation enhancements can upgrade their nuget references when appropriate, or stick with the older versions if they need to.

I agree with @Giedrius; this seems to me to be more of a source control/branching issue in the sense that if the branching/merging of Foundation is handled properly, the package management issues become moot.