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.
See http://rubyspec.org/wiki/rubyspec/Guards for the correct use of all the guards. In particular, note that the compliant_on/ not_compliant_on guarded specs will always run on MRI. The deviates_on, extended_on, and not_supported_on never run on MRI. These latter three guards will now raise an exception if passed :ruby. Also, platforms like :windows are not proper for any of these implementation compliance guards. Use ruby_version_is or ruby_bug guards for version-specific specs or specs that expose bugs in MRI.
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?.