Currently we assume packaging projects will never request its contents to be packed as framework-specific, but this might not always be the case.

For example, a packaging project that packs build tasks and targets, might request that the tasks assemblies (which are nowadays typically NS2.0) and targets be packed as framework specific to that NS2 target. Likewise, the packaging project contents themselves might also want to be framework-specific (i.e. the .targets themselves or some other artifacts might be part of that project's output too).

We need a new value that allows us to distinguish "pure authoring" projects (that just collect content from project references for packing at whichever package path those determine to be) vs more csproj-like packing where the packaging project has more to say in terms of target framework and package paths (i.e. a packaging project that references multiple other projects for the purpose of packing them all together at some framework-specific package path, potentially alongside other assets). Granted, an MSBuild-knowledged developer might get around any of this by just using <PackageFile /> everywhere, but it's an inconvenience.

We can introduce a new default value for PackFolder for packaging projects, Ignore which will behave just like today. And we can honor more specifically a BuildOutputFrameworkSpecific=true value at the project level if the PackFolder deviates from that.