I'm not exactly following your goal, here. You want the first consumer of your package to see the content (data.json), but anyone who consumes that new package should not see the content of data.json?

This MSBuild reference shows examples of how the folder structures work for Content Files: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#including-content-in-a-package
You may particularly be interested in the ContentTargetFolders and $(IncludeContentInPack) properties.

You want the first consumer of your package to see the content (data.json), but anyone who consumes that new package should not see the content of data.json?

Exactly, I do not want to include this file transitively.

Both ContentTargetFolders and $(IncludeContentInPack) will not help. ContentTargetFolders just changes destination folder. If $(IncludeContentInPack) is set to false on any project, then the content from that project are not included in the nuget package. This setting applies to all project content, not specific dependency. I have not yet figured out how to achieve the desired behavior.

The short explanation:

• This is a bug in pack. The mechanics for packing content files inside a package overlap the mechanics for flowing content files into the project they need to go to.

The long explanation:

• NuGet identifies several types of asset groups, defined here: https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#controlling-dependency-assets. contentFiles are one of those groups. When a consuming project installs a package, it allows said project to control which assets from the package in question get consumed.

• PrivateAssets controls whether the assets from the package flow to the dependants of the consuming project (or package if this project gets packaged).
  PrivateAssets=All, tells NuGet that the package in question is a development time dependency and should not be included as part of the dependencies if the consuming project gets packed.

• IncludeAssets/ExcludeAssets controls which asset groups get consumed by the current project.

• In the scenario in question, the base package is correctly created. By putting metadata such as PrivateAssets=All, NuGet understands that this package should not be flown to the dependants of the current project. When the consumer project gets packed, the BasePackage is not included in the dependency list (check the nuspec to verify that, I did that on my end).
  What does get included "accidentally" is the content that the current project is consuming. That's because of the way the content files are consumed in the current project.

• NuGet generates a nuget.g.props file to include the content files from packages into the consuming project. (In SDK based projects). If you look at the nuget.g.props file you would see:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
    <RestoreSuccess Condition=" '$(RestoreSuccess)' == '' ">True</RestoreSuccess>
    <RestoreTool Condition=" '$(RestoreTool)' == '' ">NuGet</RestoreTool>
    <ProjectAssetsFile Condition=" '$(ProjectAssetsFile)' == '' ">$(MSBuildThisFileDirectory)project.assets.json</ProjectAssetsFile>
    <NuGetPackageRoot Condition=" '$(NuGetPackageRoot)' == '' ">$(UserProfile)\Documents\Code\Test\8867\gpf</NuGetPackageRoot>
    <NuGetPackageFolders Condition=" '$(NuGetPackageFolders)' == '' ">C:\Users\Nikolche\Documents\Code\Test\8867\gpf;C:\Program Files\dotnet\sdk\NuGetFallbackFolder</NuGetPackageFolders>
    <NuGetProjectStyle Condition=" '$(NuGetProjectStyle)' == '' ">PackageReference</NuGetProjectStyle>
    <NuGetToolVersion Condition=" '$(NuGetToolVersion)' == '' ">5.4.0</NuGetToolVersion>
  </PropertyGroup>
  <PropertyGroup>
    <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
  </PropertyGroup>
  <ItemGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
    <Content Include="$(NuGetPackageRoot)\basepackage\1.0.0\contentFiles\any\any\data.json" Condition="Exists('$(NuGetPackageRoot)\basepackage\1.0.0\contentFiles\any\any\data.json')">
      <NuGetPackageId>BasePackage</NuGetPackageId>
      <NuGetPackageVersion>1.0.0</NuGetPackageVersion>
      <NuGetItemType>Content</NuGetItemType>
      <Private>False</Private>
      <Link>data.json</Link>
    </Content>
  </ItemGroup>
</Project>

Note the conditional inclusion.
The pack implementation is not consider this condition when evaluating the content to be included.

So the technical fix here is:
Pack/Restore should be updated so pack can exclude content files when evaluating the files to be included into the current package.

• Note that the PrivateAssets part is "correctly" considered by NuGet. The content files will not be flown to consumers of the project consuming base package (If curious, create project that consumes that to check it out, I did :) ). But if you end up packing the project in question, that's when issues occur.

Workaround:

As far as workarounds by the time this gets fixed go, unfortunately I can only think of the big hammer. Set IncludeContentInPack="false" in the project consuming BasePackage.

@nkolev92 Thanks for the detailed answer. I guessed that it could be a bug. But I did not understand this comment:

Set IncludeContentInPack="true" in the project consuming BasePackage.

Did you mean set IncludeContentInPack="false" in "top" package to disable packing any content from all dependencies?

As far as workarounds by the time this gets fixed go

Could you say something about when this will be fixed? In the near future is this real?

Did you mean set IncludeContentInPack="false" in "top" package to disable packing any content from all dependencies?

Yes, I meant to write that.

Could you say something about when this will be fixed? In the near future is this real?

Not sure at this point. We have lots of issue that we prioritize based on many factors.
However, we'd be happy to take a PR.

Thanks.

We have lots of issue that we prioritize based on many factors.

Yes, I looked at the current list of bugs and guessed that there was enough work there even without my problem.

However, we'd be happy to take a PR.

Unfortunately, this is not an area where I can effectively help. Actually your advice to use IncludeContentInPack="false" suits me. I write a lot of library projects, there is no content and I can use IncludeContentInPack="false" completely safely. I have already taken this approach and verified that the final behavior is what I needed.

One more note. IncludeContentInPack="false" conflicts with PackageIcon.

Warning if you use PackageIconUrl:

NU5048 The 'PackageIconUrl'/'iconUrl' element is deprecated. Consider using the 'PackageIcon'/'icon' element instead. Learn more at https://aka.ms/deprecateIconUrl

After you use PackageIcon with IncludeContentInPack="false":

NU5046 The icon file 'icon.png' does not exist in the package.

So you are locked to use PackageIconUrl yet.

Duplicate of #8867.

Duplicate of #8867.

Isn't it closed accidentally? Issue #8867: Duplicate of #8867.

We are still having this issue, when pack creates content folder with flattened content of dependencies. Isn't there a different workaround?

Wow! I didn't even notice.

Good catch!

Meant to say duplicate of #6138 :)

Reopening since this is a bug in PackageReference project. Related bug applies to packages.config projects.