Binstubs hardcoding Gemfile variant

The template for binstubs hardcode the Gemfile variant to either Gemfile or gems.rb (based on the currently used variant):

https://github.com/rubygems/rubygems/blob/db374bc25bbe024d02787336e557d9e31efc9f6d/bundler/lib/bundler/templates/Executable#L11

This comes with a nasty downside best explained with an example:

The Bridgetown SSG creates a binstub bin/bridgetown when generating a new site – or rather it has Bundler do a bundle binstub bridgetown-core --path bin. This binstub contains the hardcoded Gemfile.

Now, if you want to switch to the more syntax coloring friendly variant gems.rb, the natural thing to do is:

mv Gemfile gems.rb
mv Gemfile.lock gems.locked

Works fine in terms of Bundler, but the already generated binstubs are now broken and have to be rebuilt:

bundle binstub bridgetown-core --path bin --force

To make matters worse, Bridgetown copies this binstub to feature a shortcut and this has to be redone as well:

cp bin/bridgetown bin/bt

Since Bundler accepts both variants Gemfile and gems.rb, the binstubs generated by Bundler should do so as well IMO.

Looking at the generated binstub, it would be very easy to add a fallback to gems.rb if Gemfile does not exist. However, the template liked above shows that the actual implementation would require a few more moving parts.

Hence this issue: Is the current behavior intentional (however not "least surprise") and won't be changed or does a PR stand a chance to get merged?

Start with bundler/lib/bundler/templates/Executable at the linked line and inspect the generated binstub produced by bundle binstub bridgetown-core --path bin. Trace how the Gemfile variant is selected and what other moving parts it affects. Done means a binstub continues to work after switching between Gemfile/Gemfile.lock and gems.rb/gems.locked without regeneration.