> because `@original_method` was taken and it was the first thing that jumped to mind

Gotcha.  I think `aliased_method` is confusing because it suggests the method has been given an alternate name.  What about `unstubbed_method`?

> Cargo-culted `method_defined?` and `__send__(:method)` from other parts of the code base, honestly I'm not up to speed on which methods are defined where.

If we're going to go this route (rather than leveraging `original_method` -- see below), I think we want `respond_to?` and [`::RSpec::Mocks.method_handle_for`](https://github.com/rspec/rspec-mocks/blob/a2f952a02520d123ad18c1bdec3a8f3343dfbdc2/lib/rspec/mocks.rb#L79-L94).

Your spec below created a case where `method_defined?` worked even though it's the wrong thing, in two ways:

* It used a class as the partial mock object rather than an instance of some class (and thus `mehtod_defined?` is available).
* It used `to_s` which is available both as a class method of `Object` and an instance method of object -- so it worked to ask `Object`, "do you have an instance method `to_s`"? When we really want to ask the object "do you respond to `to_s`"?

> `original_method` returns a proc that when called calls the original method. That's not exactly what I need.

This isn't generally true.  `original_method` can get its value from 3 places:

* From the `instance_method_stasher` (see [here](https://github.com/rspec/rspec-mocks/blob/a2f952a02520d123ad18c1bdec3a8f3343dfbdc2/lib/rspec/mocks/method_double.rb#L56) and [here](https://github.com/rspec/rspec-mocks/blob/a2f952a02520d123ad18c1bdec3a8f3343dfbdc2/lib/rspec/mocks/instance_method_stasher.rb#L57).  This happens when you stub a method that is already a singleton object on the partial mock.  The instance method stasher has to stash it since it's not available on any superclass or anything like that.
* From the partial mock proxy (see [here](https://github.com/rspec/rspec-mocks/blob/a2f952a02520d123ad18c1bdec3a8f3343dfbdc2/lib/rspec/mocks/method_double.rb#L57) and [here](https://github.com/rspec/rspec-mocks/blob/a2f952a02520d123ad18c1bdec3a8f3343dfbdc2/lib/rspec/mocks/proxy.rb#L240-L250)).  It gets the original method right before redefining it with the stub version.  If the partial mock proxy can't get the method handle, it returns `nil`.
* As a fallback of last resort, it sets it to a proc that uses `method_missing` (see [here](https://github.com/rspec/rspec-mocks/blob/a2f952a02520d123ad18c1bdec3a8f3343dfbdc2/lib/rspec/mocks/method_double.rb#L22-L24)).  This allows `and_call_original` to work for objects that use `method_missing` to handle the message, or, if the object doesn't handle the message, `method_missing` will raise the appropriate `NoMethodError`, anyway.

I guess you were thinking of the last one, but that's only hit when no real `Method` object is available.  The feature that needed that before (`and_call_original`) just needed a callable and didn't need a real method object to get arity, etc, so the proc worked just fine.

From prior experience working on this stuff, I know that getting the method handle can be surprisingly slow (well, at least slower than I would expect -- see #264) and thus, it's important to me to try to leverage the original method we've (hopefully) already gotten if we can, rather than getting it again.  You might be able to do something like rename `@original_method` to `@original_method_handle`, and then make `def original_method` do `@original_method ||= @original_method_handle || Proc.new { }` -- that way you could use `@original_method_handle` and know with confidence that you're getting a `Method` object and not simply a callable that might be a `Proc`.