Any type system for Ruby objects that isn’t based on message/method response signature (i.e eigenclass), but instead relies on module ancestors (or worse, class), is fundamentally misaligned with the architecture of the language.

A remarkably high proportion of folks that self-identify as Ruby aficionados will make this error.

I’m not even talking about respond_to? / method_missing. If an object prepends a module to its singleton to become a proxy for something else, or uses refinements (which are lexical) to meet method expectations, or (bad style, looking at you Rails, but nevertheless) just evals whatever it likes after messing with the three implicit contexts, then it should still pass.

Leaning on class and mixin is just one of the ways in which Ruby object anatomy evolves, and although that’s a familiar default to many, there are other styles in common use, especially in framework/library code (and which means any app relying on such a framework may either not pass, or may silently bypass, such type checking).

Symbolic message passing is the basis of object collaboration in Smalltalkish OO, and Ruby class/mixin merely one of the ways to get there. The conceptual gap means that what you get isn’t just a half-baked type system, it’s also a crude and incomplete style enforcer.