Packages are not overwritten when already present in the built-in feed #858
Checked the NuGet.Lucene sources for clues; it seems the package file will be overwritten and the index entry updated, however it relies on there being no read locks open on the package file. Uncertain if this is likely to cause issues in reality.
To make absolutely certain we replace files when requested, let's remove existing matches first. At worst, the subsequent add might fail and no version be left remaining, however since the package required replacement the existing version is probably unwanted anyway.
If you have an a step in your automated build to publish the octopack every time the build runs - is there a way of ignoring the push if the package version is the same?
There are circumstances where the assembly version of the projects to deploy will be the same, so the existing package can be used. But pushing the same version causes nuget to error, breaking the build.