So it has worked in most situations for years.  David initially fixed this in 644e372968cd2f6aa641eb3584e87fb091a4e3c9 by adding a call to `teardown_mocks_for_rspec` from within the pending logic here.  There's cukes there showing it work with each of the mock framework adapters.

When I changed the rspec-mocks lifecycle to have the nested/stacked space support, the extra call to `teardown_mocks_for_rspec` caused a problem because it meant that the setup/teardown calls were no longer balanced.  I fixed that in 6661803d597cec4106b784137e034ce8a21ac667, which attempts to translate a failure into marking `:pending_fixed` as false.  That works for all the examples we have testing this from within rspec-core but there's an edge case I didn't think of that has now been uncovered.

The newly uncovered edge case is here in rspec-mocks:

https://github.com/rspec/rspec-mocks/blob/7b9930ba946e288c095cf9ebd3ed27d3820edb65/spec/rspec/mocks/matchers/receive_message_chain_spec.rb#L63-L73

The problem is that there are 2 separate errors that are happening.  On the `and_call_original` line, it is raising this error:

```
#<RSpec::Mocks::MockExpectationError: Double is a pure test double. `and_call_original` is only available on a partial double.>
```

This causes the pending block to immediately abort and set `:pending_fixed` to false.  Later, the mock object verification happens, and a second error is raised.  As a result, when we deal with this [here](https://github.com/rspec/rspec-core/commit/6661803d597cec4106b784137e034ce8a21ac667#diff-f6fea0ade364fa810c1e0eacf57412c9R296), `pending_fixed` is already false, so it doesn't deal with it properly.

Your solution fixes this problem, but has two downsides to it:

* It only works for rspec-mocks, not for other mock framework adapters.  While rspec-mocks is the preferred/recommended mocking library to use with rspec-core, we want to maintain feature/behavior parity as much as possible, and so we need a solution that works with other mocking libraries.
* There's the code that's meant to address this that I added in 6661803d597cec4106b784137e034ce8a21ac667.  I don't want us to maintain two separate ways to deal with this.

I think it should be doable to update the rescue logic in 6661803d597cec4106b784137e034ce8a21ac667 to handle this case.  As a side benefit, if you fix this directly in rspec-core w/o the extra rspec-mocks PR needed, there's no PR ordering dependency :).

Let me know if you have questions.