George marrows wrote:
...
> Thanks to you and Guy, I think I now understand what it's 
> doing - we could call it the 'surrounding class then 
> inheritance hierarchy' rule.
> 
> .. but I'm afraid I'm still not clear on *why* this rule is 
> used, in particular how it helps to 'make scope resolution as 
> static as possible'.
> Could you provide an example? 

You can find an example on why this probably a good idea  in 
test.rb located in the  sample directory of Ruby's source tree - grep
for "Titans" - (just image the morass of extra rules you would need to 
define to resolve this example if you start of with  a simple
``intuitive'' lookup rule).
To throw in a little history, Ruby once had more ``intuitive'' and 
seemingly simpler class variable scoping rules. However, because of
their inconstancies they were dropped, and new rules were adopted
modeled more closely around the constant scoping rules (static scope)
- not however in contrast to the former that singleton classes are 
not valid scopes  (see Guy's post) for class variables.
 
> All I see at the moment is that the rule introduces a (to me) 
> unintuitive special case for singleton methods: in Mark's 
> example, o is effectively a subclass of A, so it seems 
> strange it can't directly access its class vars.
> (See the ongoing ruby-talk discussion about objects with 
> singleton methods still being examples of their 'original' class..)
>
> Thanks again for taking the time to explain. I'll write this 
> up on the wiki when we're done.

Here is another ``weird'' example for your wiki.

---
class A
  @@var = :A
end

class B
  @@var = :B
end

class B
  $a = A.new
  def $a.var
     @@var
  end
end

class A
  $b = B.new
  def $b.var
    @@var
  end
end

p $a.var # :B
p $b.var # :A
---


/Christoph