The net net on this would be:

• Use a staged package: npm install foo@2 --include-staged (as long as 2.x versions are all in staging, like if it's a beta or somethign, and 1.x is the published versions).
• When foo@2 is promoted, then npm install foo@2 --include-staged will pick up the promoted version.
• If the staged foo@2 depends on a staged bar@3, then ok, that'll Just Work, because you're in "include staged" mode.
• When the pkg is promoted and the resolved changes, the package lock doesn't break. (It might get slightly less canonical or cacheable, but then again, it might not. Maybe we want to have content-addresses in our tarball urls!)
• If the staged version is overwritten with a new staged version, then the build will break (unless Pacote is taught to just handle this, which may be worthwhile, and would be possible.)

I don't see any DX issues that justify restricting the utility of staged packages, but maybe I'm missing something.

Originally posted by @isaacs in #92 (comment)