I hadn't really thought through your `@method_is_proxied = false` line to realize the repercussions of it, but I can see that's the result it has now.  There are a couple potential issues I can see with this behavior:

* Prior to now, I believe that stubs were always reset.  Among other things, this ensures that a double's stubs would not "leak" between examples if the user tried to use it in another example, given that we intend a double to only live for one example.  We're talking about enforcing that life cycle more explicitly in #352 but we're not there yet.
* In #399, @JonRowe is adding support for `allow(some_object).to receive_messages(foo: 3, bar: 5)`.  I suggested he build that on top of your simple stubs since it only supports message/return-value pairs.  However, in that case, the object may be a partial mock (i.e. real) object, and it's super important that they get reset properly...otherwise `allow(MyClass).to receive_messages` will leak its stubs and cause test ordering dependencies :(.

Was the choice to not reset anything based on wanting to optimize perf?  I'm thinking that in #352 we can make the self-destruct thing be what `reset` does on test doubles, but until then, it should probably reset the stubbed methods here.

Thoughts?