If there's one thing I wish Ruby would adopt from python it's the import namespace system. Then this kind of proposal would become more practical.
For requires going stale, I mean when a file originally depends on something but no longer does. The require is likely to linger, especially if the dependency is removed without knowing that it was the entirety or the last of the dependency. This file now has stale dependencies.
Then something requiring that file will have that dependency in place and possibly use it without requiring it because of that. This file now has incorrect dependencies.
Expand the above across a more complex project and it becomes virtually impossible to verify the correctness of your requires, so you probably just stop trying and require things as needed, which makes it worse.
When you finally discover it your changes (in your version control) become less isolated as random requires start popping in and out.
This is not a new or unique problem to Ruby, obviously. C/C++ headers have a very similar problem.
:require => false
> Manually requiring dependencies at the top of every file very explicitly tells you and anyone else exactly what dependencies that file has.
While I don't disagree with this statement, I don't really know of any way to enforce it (certainly using Bundler.setup won't do so). You're always going to have everything that has been required elsewhere "pre-required" for you. I'll often start out explicitly requiring everything that a file needs when I start a project, and then end stopping when I look back at some file and notice that it lacks require statements for half the stuff it needs.
Again, I tend to agree with you more than I disagree. I think were I disagree is in making it a recommendation -- if someone is on point enough to effectively use Bundler.setup, I don't know that they need to have it recommended to them; they just need to know the difference between Bundler.setup and Bundler.require. On the other hand, if someone does need a recommendation and not a description, I'm not sure that either is the appropriate response.
I guess at the end of the day, I'm just not looking forward to the change-sets this might generate ;)