[Feature Request] Disable caching for Local Feed

[gioce90]

NuGet Product(s) Involved

NuGet.exe, NuGet SDK

The Elevator Pitch

I'm asking the same feature in #8251 , in light of new clearer reasons of which is the common scenario that the feature will resolve.

For local development purposes this feature is a must-have: I exhaustive described here a common scenario, but - shortly - the idea is to give to developers the freedom to works on their local machines using Local Feeds without facing cache issues.

This is especially needed when we work on 2 or more local projects, where one is a package project and the other is a project who consumes the package. When a developer make some changes on a package, before to push these changes he wants to test the changes using (in local) other project(s) which consumes the edited package. All of this happens in local and doesn't involve yet the CI/CD pipelines. This is a really common scenario in companies with large codebase and numerous package projects.
Note that the purpose here is not to skip the CI/CD, but just speed-up the local development.

So the request is: only and exclusively for packages on the local machine, that the cache should be disabled.

It could be by default or, as suggested here, with this configuration:

nuget.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
     <add key="Local packages for Windows" value="%userprofile%\.nuget\packages\localPackages"  disableCache="True" />
     <add key="Local packages for MacOS" value="~/.nuget/packages/localPackages"  disableCache="True" />
  </packageSources>
</configuration>

Of course disableCache="True" should works only for local feeds.

Another solution it can be to operate on the in the .csproj in this way:

<Project Sdk="Microsoft.NET.Sdk">
         ...
	<ItemGroup>
		<PackageReference Include="MyPackage" Version="8.0.0-Local" disableCache="true" />
	</ItemGroup>
</Project>

Any other ideas on how to disable cache for packages on the local machine are welcome.

Additional Context and Details

In local I use to produce a package using this convention: MyPackage.x.y.z-Local ... now, we all knows that increment the version is really important when we are shipping the package, but in local it should not be a serious thing, because is just distracting and a waste of time and focus.
But using just the "-Local" suffix without increment the version means facing cache issues: this should due to global packages folder that keep the old package (I don't think that http-cache is involved).

Note:

• In NuGet there are already several ways to skip cache, but not via .config or .csproj
• Being forced to continuously increment the version number on both the package project and the project that references it, when we are still working locally, is non-sense [IMHO].
• Typically a pre-release version of a package is built via CI/CD related to a feature branch: but being forced to push changes to start this pipeline, only to debug and test locally something a developer isn't entirely sure about, is a waste of time, resources (pipeline agents), and an unnecessary mess of git history. And have to wait the pipeline execution just to take the new pre-release version that then will however tested in local by the other project... is a waste of time and focus.
• Avoiding this cache problem with the use of CLI commands, custom Powershell scripts, Directory.Builds.props (which is my case), clean all the cache manually every time... all of this is a burden that the feature proposed resolves.
• Note that substitute the <PackageReference> tag with the more directly <Reference> tag in the .csproj of the project who uses the package expose to easy mistakes and compromises other things.
• A fallback Package Folders doesn't resolve the problem (as initially pointed out in the closed issue).