Exclude outdated NETStandard.Library and its dependencies from restore graph on newer projects.

[TheXenocide]

Handling of NETStandard.Library as an implicit reference has improved with newer target frameworks and the packages generated by them using the Pack target, but there are many valid packages in the wild that still bring in the older NETStandard.Library references (e.g. 1.6.0) which seemingly brings in lower versions of many of its dependencies/their transitive dependencies/etc (e.g. System.Linq v4.1.0, System.Net.Http, System.Security.Cryptography.X509Certificates).

It seems MSBuild does a better job handling these scenarios when compiling, but there's a certain ambiguity when trying to perform dependency analysis using the project lock file or while browsing the package hierarchy in Visual Studio. Would it not be possible to ignore these libraries for projects that use newer platform foundations? For example, we have libraries that target netstandard2.0 and applications that target net48 and net6.0 that, according to project.assets.json, appear to bring in lower versions of libraries than any of those platforms would (should?) actually use.

We have a number of scenarios that involve soft references/dynamic assembly loading/etc. and have had issues with transitive version conflicts otherwise. While trying to analyze projects to determine which versions of assemblies are being requested by various dependencies and which are actually being restored by various projects we see large swathes of apparent dependency conflicts coming from different libraries incorporating different versions of these dependencies and, even assuming it would correctly use newer versions of these dependencies because of the newer target frameworks, those results do not appear to be reflected in the available data. It generates a lot of noise in our analysis and seems like it would also be unnecessary to even download outdated versions of most of these packages in many cases.

Is there no way to make this behavior less intrusive, more friendly, and otherwise more obvious what versions we should expect are actually being used?

Side note: we would really love to use newer CPM features like transitive version pinning rather than having to manually override versions with explicit references in tons of individual projects, but it's unclear if we should ever expect it to be supported for our particular needs (we currently share package versions and other features across many separate repositories using custom project SDKs to avoid duplication, e.g. copy/pasting Directory.Packages.props in every repository; ideally we would like other implicit directory features, like editorconfig, to be configurable via project SDK too since it gives much better reuse).

From this other discussion, it appears we are not the only ones likely to be doing this kind of analysis. Perhaps it's just the discussions I've looked at, but I've yet to see much conversation from the project team on any of them. Does the team actively participate in this Discussion section on GitHub or should I be creating these as issues? I was thinking it might help to discuss the hows and whys and such before creating tickets, but maybe it doesn't fit the workflow here? Just curious what the recommended interaction should be for this project.

EDIT: After reading some more discussions, it appears that maybe @zivkan is a member of the team actively participating in the Discussions tab. Perhaps there are priorities/schedules I'm not aware of that dictate how often these get focus.