Since 1.8 does not canonicalize the filename that is required, the same file can be required multiple time. This is particularly true for spec_helper.rb, however it could also affect execution of the specs. On 1.9, the path is canonicalized. Using File.expand_path should eliminate this difference on 1.8 and 1.9.
Ruby method dispatch behavior calls #method_missing if an instance has no method corresponding to a particular selector. Ruby also defines a number of methods, for example, #to_ary, #to_int, #to_str, that form an interface to Ruby's ducktyping behavior. String methods, for instance, may call #to_str when passed an argument that is not a String. The point of the rubyspecs is to describe behavior in such a way that if two different implementations pass a spec, Ruby code that relies on behavior described by the spec will execute with the same result on either implementation. If a spec asserts that a method calls #to_int on an object, it is immaterial to the final outcome whether an implementation calls some way, or first calls #respond_to?(:to_int) and then calls #to_int. There are only two significant aspects to this from the perspective of user code (i.e. code using the interface, not code implementing the behavior): 1) #to_int is called and performs some action; or 2) It is conceivable that user code like the following exists: class Silly def method_missing(sym, *args) return 1 if sym == :to_int end end In such case, the behavior of the following code would be different: # The implementation calls #to_int without checking #respond_to? [1, 2].at(silly) # => 2 # The implementation calls #respond_to? first [1, 2].at(silly) # => TypeError In the second case, the expected behavior is restored if the Silly class is modified to implement a #respond_to? for :to_int. The point is that it really is not sensible to implement an object that provides an interface but does not let the world know about it by either 1) defining the method properly, or 2) defining #respond_to? to indicate that the object provides the interface. If real-world code exists that _depends_ on this silly implementation (i.e. cannot be coded in a more realistic way), then we can revisit the utility of specs that require #respond_to? to be called. Otherwise, these specs are too tied to the implementation and impose an unrealistic burden on implementations that may exhibit perfectly compatible behavior but not call #respond_to?.