NuGet Product(s) Affected

Visual Studio Package Management UI

Current Behavior

Per semver, new major versions are allowed to introduce breaking changes in their API.
Yet NuGet will not inform of any potential problems and will download packages with a higher major version than specified by a dependency, unless the dependency explicitly specifies a maximum version in its PackageReference.

To demonstrate using purely MS packages:

1. in Visual Studio (currently using 2019), create a new project using the template "ASP.NET Core Empty"
2. in the wizard, check the box "Run on .NET Framework"
3. (optionally) upgrade the .NET Framework and all nugets in the project to their latest available versions
4. add the nuget Microsoft.Azure.Devices.Client 1.39.0 to the project
   When run, the app immediately crashes. Now continue:
5. Remove Microsoft.Azure.Devices.Client again
6. Add the nuget Microsoft.Azure.NotificationHubs 4.1.0
   Run again. It will not crash, but won't run either. After disabling "Just my code" in Visual Studio, you'll notice exceptions somewhere deep, preventing the app from running properly.

These are just two examples that are easy to reproduce, but we found more during our recent package upgrade. At this point, we are unable to tell confidently whether our application is fine, or if some new issue will appear when our app hits an uncommon execution path.

I know that NuGet would be able to warn about the potential incompatibilities if every PackageReference in every nuget was version locked to the current major version. But since MS does not do that, nobody will.

Desired Behavior

At least, NuGet should print a warning.
This means: if any PackageReference does not contain an explicit maximum version, then assume that it is only compatible with the current major version, as specified by the minimum version of the PackageReference. (If the package author did include a maximum version, then no change in behavior is needed)
There could also be an option to turn this warning into an error, so that developers cannot ignore this.

Ideally though, NuGet should be able to suggest ways how to resolve these issues. If applied to the case described previously, NuGet should suggest to downgrade Microsoft.Azure.Devices.Client or Microsoft.Azure.NotificationHubs, and also determine to which version. Debian's apt system can do something like this.

Additional Context

This isn't new, it is also known as the Diamond dependency problem and discussed here: https://codeblog.jonskeet.uk/2019/10/25/options-for-nets-versioning-issues/
That blog suggests other solutions to this problems, but printing a warning is I think the least NuGet can do, and would be sufficient in many cases.

People are being hit by this problem, and it seems that they simply try randomly upgrading/downgrading, until the application seems to works. For example:
#6673 (comment)
https://stackoverflow.com/questions/59402761/system-methodaccessexception-attempt-by-method-microsoft-extensions-logging-c
https://stackoverflow.com/questions/66416331/could-not-load-type-microsoft-extensions-primitives-inplacestringbuilder-from