Aparte: you should put the explanation right into the commit message, not just on GitHub PR; Git log or blame, for example, would be very enriched :-)

I'll do it, please don't merge yet 👍

Updated!

So, after this change the code class vars are shared among all the instantiations

class Foo(T)
  @@counter = 0

  def self.inc
    @@counter += 1
  end

  def self.counter
    @@counter
  end
end

pp!({Foo.counter, Foo(Int32).counter, Foo(String).counter}) # => {0, 0, 0}
Foo.inc
pp!({Foo.counter, Foo(Int32).counter, Foo(String).counter}) # => {1, 1, 1}
Foo(Int32).inc
pp!({Foo.counter, Foo(Int32).counter, Foo(String).counter}) # => {2, 2, 2}
Foo(String).inc
pp!({Foo.counter, Foo(Int32).counter, Foo(String).counter}) # => {3, 3, 3}

I came late to the discussion (holidays \o/) but I think a more proper behaviour would have been to let Foo(Int32) and Foo(String) have their own class variables and disable Foo without instantiation here. Foo could be used as a namespace component without instantiation as it can be used today.

With the above proposed behavior user can share state among metaclasses instance with a dummy type and isolate state by declaring class vars directly inside the generic type.

I found that would be even more consistent with respect non generic class hierarchy.

class Bar
  @@counter = 0

  def self.inc
    @@counter += 1
  end

  def self.counter
    @@counter
  end
end

class Baz < Bar
end

class Qux < Bar
end

pp!({Bar.counter, Baz.counter, Qux.counter}) # => {0, 0, 0}
Bar.inc
pp!({Bar.counter, Baz.counter, Qux.counter}) # => {1, 0, 0}
Baz.inc
pp!({Bar.counter, Baz.counter, Qux.counter}) # => {1, 1, 0}
Qux.inc
pp!({Bar.counter, Baz.counter, Qux.counter}) # => {1, 1, 1}

Yeay! C# behaves as I proposed https://stackoverflow.com/questions/14748569/is-a-static-member-variable-common-for-all-c-sharp-generic-instantiations

@bcardiff , I agree that this a good question to refer to language ideas. Which are a bit unclear for me after point of diverging from Ruby. With this PR it looks to be Java-like approach (any "class" regardless of it being generic or specialized represent single entity) and refer to Foo(Int32) vs Foo(string) as a single class though instances of it being annotated with different types (like phantom types) to carry additional information.
It still can be justified. Similar as in Java you can say that as soon as you create a specialized class (class FooInt32 < Foo(Int32)) you'll get unique treatment. Though I somehow prefer "templates" from C++ over "generics". And I was a bit surprised to find absence of "templates" in Crystal while having compile-time macros and implicit union types.