> > isn't <=>+checking for same class enough for this?
> 
> At the moment,
> 
>   (3..5).member?(3.5)    #=> false
>   (3..5).member?(4.0)    #=> true
> 
> so following your rule exactly wouldn't duplicate the current behaviour.

Also, your rule requires that 'succ' generate all possible intervening
values between the two bounds, with no gaps. So to give a stupid
counterexample:

  class Foo
    attr_reader :x
    def initialize(x); @x=x; end
    def succ; self.class.new(@x+@x); end
    def <=>(y); @x <=> y.x; end
    def ==(y); @x == y.x; end
  end
  (Foo.new(1)..Foo.new(64)).member?(Foo.new(32))  #=> true
  (Foo.new(1)..Foo.new(64)).member?(Foo.new(33))  #=> false

An optimised member? test would need to be coded specially for this class -
or fall back to iteration. Consider also:
   (Foo.new("x")..Foo.new("xxxxxxxx")).each {|x| p x} 

I agree with Matz - Range#member? is not very useful. For the occasional
case where you might need such semantics, it's easy enough to code up your
own object which behaves how you want.

You can argue that a Ruby Range shouldn't be able to iterate then, but I
just see it as a freebie bonus behaviour, which is actually useful in
practice.

Regards,

Brian.