Behavior of local_variables in Ruby 1.8 vs 1.9

Witness:

Ruby 1.8.6:
$ ruby -e "p local_variables; a = 1; p local_variables; b = 1; p 
local_variables"
["a", "b"]
["a", "b"]
["a", "b"]
$ ruby -e "proc { p local_variables; a = 1; p local_variables; b = 1; p 
local_variables }.call"
[]
["a"]
["b", "a"]

Ruby 1.9:
$ ruby1.9/ruby -e "proc { p local_variables; a = 1; p local_variables; b 
= 1; p local_variables }.call"
["a", "b"]
["a", "b"]
["a", "b"]
$ ruby1.9/ruby -e "p local_variables; a = 1; p local_variables; b = 1; p 
local_variables"
["a", "b"]
["a", "b"]
["a", "b"]

Now I presume the 1.8 behavior is due to block-local variables being 
managed in a dictionary, rather than by a static scoping structure as in 
Ruby 1.9. I prefer the 1.9 behavior here.

JRuby manages variables like 1.9, in static scoping structures, but up 
to now we have emulated the 1.8 behavior for local_variables within a 
block. However this requires that for all block-local variables, we have 
checks on every access to ensure that "nil" is returned for unassigned 
variables. This is overhead I'd like to eliminate by filling all 
variables with nil to begin with, but that would prevent us from knowing 
which variables to show in local_variables, since they're technically 
all initialized to nil.

I believe that the 1.8 behavior is largely just a side-effect. If it 
could be regarded as such, it would be reasonable for other Ruby 1.8 
implementations to omit the behavior and have local_variables act the 
same everywhere, as in Ruby 1.9.

Matz, do you consider the 1.8 behavior correct or the 1.9 behavior 
correct? Would you consider the 1.8 behavior a feature that should be 
emulated in other implementations of 1.8?

- Charlie