When using the TargetFrameworks property in a project, a Build called "inner build" is run as part of the main Build target, for each defined target framework.
The issue is that the Pack target is also running for those inner builds, when it shouldn't. The reason why it shouldn't is because the Pack should run just once as part of the main Build target and include the outputs for all the target frameworks as sub folders inside the .nupkg. Running also for inner builds causes the .nupgk to be generated more than once and just for a single target framework, overriding the previous one. This ends up getting a .nupkg with only one target framework folder (the latest defined in the TargetFrameworks property).

If the Pack target is run separated from the Build target (/t:Pack), it runs correctly; which confirms the theory that what is causing the problem is the combination of Build + Inner Builds (multi targeting) + Pack.

A workaround has been found and consist of defining the following target in the .csproj or in the Directory.Build.targets file:

<Target Name="PackAfterInnerBuilds" AfterTargets="DispatchToInnerBuilds" DependsOnTargets="Pack" />

Note that DispatchToInnerBuilds is a target defined in Microsoft.Common.CrossTargeting.targets and it's the one responsible of running the inner builds for each target framework, so by running an extra Pack after this completes, we ensure that the malformed .nupgk is overriden with a correct one including all the target frameworks.

Of course this is not performant and it's just a workaround. This issue is reproducible by just creating a single .net Standard Class Library and editing the .csproj like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net472;netstandard2.0</TargetFrameworks>
  </PropertyGroup>

  <PropertyGroup>
    <PackageId>TestNuGetizer</PackageId>
    <Description>Test Package</Description>
    <PackOnBuild>True</PackOnBuild>
  </PropertyGroup>
  
  <ItemGroup>
    <PackageReference Include="NuGetizer" Version="0.4.12" />
  </ItemGroup>
</Project>

Then build the project and observe the resulting .nupkg that contains just a single target framework folder in lib instead of two.