Poor error reporting of platform conflicts

When using a gem that has native extensions for MRI and JRuby, one can change Ruby interpreters and have bundle install work transparently:

speed% mkdir test
speed% cd test
speed% cat >Gemfile
source 'https://rubygems.org'
gem 'bson'
speed% rbenv shell 2.5.1
speed% bundle install
Fetching gem metadata from https://rubygems.org/...............
Resolving dependencies...
Using bson 4.3.0
Using bundler 1.16.2
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
speed% rbenv shell jruby-9.2.0.0 
speed% bundle install           
Fetching gem metadata from https://rubygems.org/...............
Resolving dependencies...
Using bson 4.3.0 (java)
Using bundler 1.16.4
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

However, when running bundle install from within such a gem, things fail in a very confusing fashion:

speed% git clone https://github.com/mongodb/bson-ruby
Cloning into 'bson-ruby'...
remote: Enumerating objects: 7486, done.
remote: Total 7486 (delta 0), reused 0 (delta 0), pack-reused 7486
Receiving objects: 100% (7486/7486), 1.50 MiB | 7.27 MiB/s, done.
Resolving deltas: 100% (3996/3996), done.
speed% cd bson-ruby 
speed% rbenv shell 2.5.1
speed% bundle install
[bson] Warning: No private key present, creating unsigned gem.
Fetching gem metadata from https://rubygems.org/........
Resolving dependencies...
Using rake 12.3.1
Using bson 4.3.0 from source at `.`
Using bundler 1.16.2
Using coderay 1.1.2
Using diff-lcs 1.3
Using json 2.1.0
Using method_source 0.9.2
Fetching pry 0.12.2
Installing pry 0.12.2
Using rake-compiler 1.0.5
Using rspec-support 3.8.0
Using rspec-core 3.8.0
Using rspec-expectations 3.8.2
Using rspec-mocks 3.8.0
Using rspec 3.8.0
Using ruby-prof 0.17.0
Using yard 0.9.16
Bundle complete! 8 Gemfile dependencies, 16 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
speed% rbenv shell jruby-9.2.0.0 
speed% bundle install           
[bson] Warning: No private key present, creating unsigned gem.
Fetching gem metadata from https://rubygems.org/........
Could not find gem 'bson' in source at `.`.
The source contains 'bson' at: 4.3.0 java

Just looking at the error message:

Could not find gem 'bson' in source at `.`.
The source contains 'bson' at: 4.3.0 java

... it is very confusing why bundler cannot find 'bson` when it immediately reports that 'bson' is present.

The fix is to remove Gemfile.lock, then bundle install works:

speed% rm Gemfile.lock 
speed% bundle install 
[bson] Warning: No private key present, creating unsigned gem.
The dependency ruby-prof (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for java but the dependency is only for ruby. To add those platforms to the bundle, run `bundle lock --add-platform ruby`.
Fetching gem metadata from https://rubygems.org/........
Resolving dependencies.....
Using rake 12.3.1
Using bson 4.3.0 (java) from source at `.`
[bson] Warning: No private key present, creating unsigned gem.
Using bundler 1.16.4
Using coderay 1.1.2
Using diff-lcs 1.3
Using ffi 1.9.25 (java)
Using json 2.1.0 (java)
Fetching method_source 0.9.2
Installing method_source 0.9.2
Using spoon 0.0.6
Fetching pry 0.12.2 (java)
Installing pry 0.12.2 (java)
Fetching rake-compiler 1.0.5
Installing rake-compiler 1.0.5
Using rspec-support 3.8.0
Using rspec-core 3.8.0
Using rspec-expectations 3.8.2
Using rspec-mocks 3.8.0
Using rspec 3.8.0
Using yard 0.9.16
Bundle complete! 8 Gemfile dependencies, 17 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

Perhaps adding a platform indication to Could not find gem 'bson' in source at .. would fix this. Or a more verbose explanation that the lock file is for the wrong platform.

Reproduce the reported bundle install sequence while switching between MRI and JRuby, keeping the existing Gemfile.lock. Trace the platform-conflict handling that produces the source lookup error; done means the message clearly explains the lockfile/platform mismatch or identifies the relevant platform in the existing error.