When converging specification to pass the set of versions that should be
preserved from the lockfile during resolution, we should make sure all
top level gems are considered, and only exclude those gems themselves
(and not their dependencies) if their locked versions happen to not be
satisfied by an edited Gemfile.

https://github.com/rubygems/rubygems/commit/ed2f1b7b88

After having a second look at this deprecation, the explanation that
we're giving does not make a lot of sense. When working only with local
gems, Bundler will indeed generate a different lockfile depending on
the latest installed version of each gem is at `bundle install` time.

That's the same situation that happens with remote sources: Bundler will
generate a different lockfile depending on the latest version of each
gem available remotely.

So, I don't think "a consistent lockfile not getting generated" is a
good motivation for deprecating this.

Also, this deprecation brings additional challenges, since for example,
it should arguably not get printed when using `bundle install --local`?

The original problem when this deprecation was introduced was an
incorrect message about a missing gem having been yanked.

So, I think a better solution is to, as long as we give proper error
messages when things go wrong, let users do what's best for them and
undo the deprecation.

https://github.com/rubygems/rubygems/commit/17499cb83f

https://github.com/rubygems/rubygems/commit/d478ec403f

https://github.com/rubygems/rubygems/commit/07e7f0bf5e

It gives better errors.

https://github.com/rubygems/rubygems/commit/bedae080ef