One of the reasons I favor two classes (w/o the separate strategy) is because this class currently has two entirely separate sets of APIs:

* `.stub_chain_on`/`#stub_chain`
* `.expect_chain_on`/`#expect_chain`

You either do use one set or the other, never both.  So it feels very odd to me to keep them on the same object given that these uses are disjoint.  To me, it would feel more natural to have two separate classes that implement the same interface (and potentially use a base class for implementing the common bits).