as a developer, i would expect the old (1.8.6) behavior. i've had arguments that the new behavior is more "correct", as there is no actual script running when the requiring of bar.rb takes place. however, from this correctness, there arises no advantage whatsoever. i am strongly in favor of the old behavior.
=end

consider two files, foo.rb and bar.rb, both simply contain: "p $0". i run "ruby
-rbar.rb foo.rb".

using 1.8.6 and the same setup, the output is:

"foo.rb"
"foo.rb"

using 1.9.1p0 the output is:

"ruby"
"foo.rb"

as a developer, i would expect the old (1.8.6) behavior. i've had arguments
that the new behavior is more "correct", as there is no actual script running
when the requiring of bar.rb takes place. however, from this correctness, there
arises no advantage whatsoever. i am strongly in favor of the old behavior.

I would argue that the 1.9 (and 1.8.7) version is a better
representation of the actual state of the program.

Further, though, I cannot see a valid use case where the
script being required with -r should know the name of
the assumed eventual script: to me, it implies a problem
with the design and/or the separation of responsibilities.

As always, there may be some use case I am missing?

The "$0 == __FILE__" trick obviously works the same in both
implementations.

my own use case is a bit hacky and has only syntax advantages:
i'm trying to intercept certain command line arguments, for example
in "ruby foo.rb -test" i would intercept the "-test" and
exec "ruby ./.tests/t_foo.rb" (which is a test suite for foo.rb
previously generated). this is all done in the script "pre.rb"
which i require by the rubyopt environment var (-rpre.rb). it would
need $0 to easily get name of the executed script; there are even
hackier ways of course. i admit that this use case is probably not
very meaningful nor a good design idea. i'd personally like it,
though.

anyway, let us suppose there is no valid use case. you wrote:

Further, though, I cannot see a valid use case where the
script being required with -r should know the name of
the assumed eventual script: to me, it implies a problem
with the design and/or the separation of responsibilities.

we can take this a step further to find ourselves posing
the following questions:

is there any difference between -r'd and require()'d scripts
regarding the script that is actually run? no!

we can then ask: is their a valid use case for
require()'d scripts to know $0?

if not, is their any valid use case except the
$0 == FILE trick?

yet further, what is the point of having $0 if we only
need it for the trick mentioned above?

the main thing that buggers me though is that $0 == "ruby"
comes totally unexpected. i would never expect it to hold
"ruby" (except when the file itself is named ruby), and i
don't think the average developer would.

i hope my points were clear enough.

regards, morris

update:
additionally, why is ARGV fully available in the -r'd scripts?
we'd have to artificially "hide" ARGV and $0 by your arguments.
that does not make much sense to me.
=end