I've been going through the book all day long, but I'm not too enthusiastic about it. It focuses so much on the "coding" that it seems to transcend the human aspect of it, that is, there will be developers that are not able to properly split classes, there will be teams, there will be incorrectly shaped boundaries, time constraint and even language limitations.

The book seems to be great at doing an incredible analysis of an OOP language, but it doesn't seem to consider the fact that the human portion of it matters a lot.

Sometimes generalizing the code so that it supports all use-cases is more expensive than just rewriting the part of the code that will change. This statement is what feels my thought as I read through the book. And even in the analysis, it seems to focus on the ideas, but not why (and numbers) that brought to this.

I bring a simple example. I have no idea what this class does:

    class Foo < Bar
    end

I know exactly what this one does:

    class Foo
      def initialize
        @bar = Bar.new
      end
    
      def something
        @bar.something
      end
    
      def whatever
        @bar.whatever
      end
    end

With the tools you described, it makes sense, you can achieve this, but without them, the problem becomes serious.

The "advantage" of the first one is that when Bar changes its public interface, Foo will change too. I don't think this is a good idea. It's nice you have to write less, but whenever a public interface changes, it should break things.

Then again, I definitely didn't write a book or have any numbers. I'll keep going through the book, but it's been quite frustrating. Very academic, so I have to skim chunks of it.

It is great that you are looking into OOSC2. Yes Meyer is somewhat difficult to read since he is so thorough, precise and detail-oriented that it can become tedious at times. Take your time going through the book to get the big picture of his OO design/implementation arguments rather than the details of the Eiffel language (not necessary during the first pass). It is a huge book so skip topics as needed to focus on the essential concepts.

You should also look into Meyer's "Design By Contract" technique for writing "correct" OO and other-paradigm programs. This is of great value in real-world programming.

PS: You might also find another Meyer's book Agile! The Good, the Hype and the Ugly quite instructive - https://learning.acm.org/techtalks/agile