I'm one of the authors of the book, so I hope you liked it! We're working on a second edition with lots of new content, and this particular case is being tackled as well.
Just to clarify, the CI --> QA --> PROD scenario is set as an example package promotion flow: you can create your own if you like.
You point is correct: package promotion should not require any modifications to the package nor its contents. This effectively means there's not even a rebuild of the binaries inside of your package when promoting it to another feed. The only exception to this rule is the package prerelease version, which can be adjusted or removed. Note: the semantic version should stay the same when promoting!
This is a core feature of http://www.MyGet.org: here's the documentation for it http://docs.myget.org/docs/reference/package-sources (scenario: pushing package upstream).
The above principles are applied in this feature, and we also take care of feed security/api keys. If you do not use MyGet, then you'll need to do this for yourself. The logical steps are:
- download the package from the source feed
- optionally change the prerelease tag (manually?)
- push the package to the target feed
Many open source projects are using this scenario, using a CI feed on MyGet.org and then pushing upstream to NuGet.org. The upstream package source can be any other NuGet feed (e.g. Chocolatey.org gallery, Resharper plug-in gallery, another MyGet.org feed, ...).