expect {E}.to_not change{X}.from(F) should fail with "should have initially been F but was f"

I could be a minority here, but I keep finding myself expecting `from()` to work the same with a `should_not change` as it does with a `should change`.

The problem is that there are 2 very different ways of interpreting `should_not change{X}.from(F)`...

It could either mean:

> (1) X *should* initially have a value of F; and this block should NOT cause X to change *from* this initial value (to *any* other value)

Or it could be interpreted as:

> (2) X **MAY** change its value **AS LONG AS** it does *not* change from this specific forbidden "from" value F (in other words, the "from" value must be anything ***other*** than F)

I believe both interpretations are valid. The `change` matcher currently implements the (2) interpretation... and this could *occasionally* be what you want, but IMHO I believe option (1) makes more intuitive sense, is a stronger test/expectation, and is more useful more often than is option (2).

(I believe the potential for confusion is probably a problem in general with `should_not` expectations, but for now just dealing with `should_not change`...)


## (2) X **MAY** change its value **AS LONG AS** it does NOT change from this specific forbidden "from" value F)

This interpretation may be described with the following examples:

```ruby
  before(:each) do
    @instance = SomethingExpected.new
    @instance.some_value = 'initial'
  end

  it "passes because it was changed from an initial value of 'initial' and we merely specified that it must not change from an initial value of 'dog'; changing from *any* non-'dog' value is still allowed" do
    expect { @instance.some_value = "cat" }.to_not change(@instance, :some_value).from("dog")
  end

  it "fails because it was changed from an initial value of 'initial' and we explicitly specified that it must *not* change from that specific value" do
    expect do
      expect { @instance.some_value = "cat" }.to_not change(@instance, :some_value).from("initial")
    end.to fail_with(%(some_value should not have changed, but did change from "initial" to "cat"))
  end
```

While this makes sense on some level, I have yet to see a practical example of when it would actually be useful to express an expectation like this.

If you really *are* okay with the value changing from *some* value F but *aren't* okay with it changing from some value G, then it seems like you should be writing this is as a (positive) *should* expectation about the change you *do* expect to see, rather than as a (negative) *should_not* expectation:

```ruby
  it "should change from 'F' to 'cat'" do
    expect { @instance.some_value = "cat" }.to change(@instance, :some_value).from("F").to("cat")
  end
```

On the one hand, a `should_not change().from()` expectation seems *too specific to be useful*. It would be like testing a bunch of specific *unexpected* values:
```ruby
x.should_not == 1
x.should_not == 2
...
x.should_not == 99
```

instead of simply expressing in the positive what the *expected* value is:
```ruby
x.should == 100
```

On the other hand, this interpretation does more closely parallel the difference in meaning between, say:

```ruby
x.should == 99       # equality with a very specific value
```
and
```ruby
x.should_not == 99   # inequality with the same specific value
```

So to be fully consistent with *that* behavior I suppose it might make sense to implement the way it is currently implemented.

But that might be a poor comparison since `should ==` is not a complex matcher with *parameters* (`from()`, etc.) like `change` is... 

Besides, the `failure_message_for_should_not` message "should not have changed, but did change" makes it sound more like we're broadly testing that there was NO change at all than it sounds like we're testing that we didn't change in one very specific way (but *may* have changed in some other specific way that we didn't consider).

It seems like as a tester it's all too easy to fail to test every single way in which something should **not** change or behave... and end up shooting ourselves in the foot down the road when some change produces some unwanted behavior that we *forgot* to specify as disallowed... This is probably the case with a lot of different matchers when using `should_not`, not just `should_not change` . But now I'm rambling, sorry...


## "Strengthening" tests by passing additional parameters to the matcher...

Currently when you add a `from()` parameter to a `should_not change` expectation, you actually "*weaken*" the test. So instead of "X should not change at all", when you add a `from(F)`, you change it to mean "X can change practically any way it wants to (!) AS LONG AS it didn't start out with a value of F".

With proposed behavior (2), on the other hand, the meaning continues to be "X should not change at all" when you add a `from(F)`, and then it adds *additional* expectations on top of that: "X should have an initial value of F".


## (1) X *should* initially have a value of F; and this block should NOT cause X to change *from* this initial value

Here's a more real-world example of when I'd want it to behave like interpretation (1)...

```ruby
    describe "when we attempt to re-import the file" do
      context "the file's timestamp is newer than the existing item" do
        it('should update the existing item') {
          expect { expect {
            do_import
          }.to change(Import, :count).from(1).to(2)
          }.to change { Item.last.name }.from('Test Item').to('Updated Item')
        }
      end
      context "the file's timestamp is older than the existing item" do
        it('should not update the existing item') {
          expect { expect {
            do_import
          }.to_not change(Import, :count).from(1)
          }.to_not change { Item.last.name }.from('Test Item')
        }
      end
```

When I discovered that the 2nd test here was passing even though `Item.last.name` was *not* initially 'Test Item', I was pretty confused. It felt like RSpec was silently ignoring my `from()` parameter!

And if it's just going to *ignore* it, I decided, then it would be better to *remove* the `from()` altogether so that future test readers wouldn't think that it's testing something that it's *not*!

Of course, I *could* always just add a separate expectation to test the "before" value, like this (and ended up doing so):

```ruby
      context "the file's timestamp is older than the existing item" do
        it('should not update the existing item') {
          Item.count.should == 1
          Item.last.name.should == 'Test Item'
          expect { expect {
            do_import
          }.to_not change(Import, :count)
          }.to_not change { Item.last.name }
        }
      end
```

but it seems like it would be cleaner to just roll all that into my "not change" expectation... (After all, you *could* unroll *any* "change" expectation into a series of expectations before and after the code in `event_proc`... but the whole reason I want to use the nice rspec matchers is to express expected behavior more cleanly and concisely and, in this case, without repeating myself.)


### `failure_message_for_should`

Another possible argument for this special "should_not change from" behavior is that the "should have initially been" failure message within `failure_message_for_should` is already a bit of a special case. All of the other failure messages start with "should have been changed" and take into account both what the value was *before* and what the value changed *to*, whereas "before" message is the only one that looks only at the state of things *before* the proc was called.


## Conclusion

So there you have it — my case for changing this behavior. I'd love to hear what you think (and, if possible, point out a real-world example of when the current  behavior works well)...

Even if we don't *change* the behavior, perhaps the docs and specs could be expanded to be clearer about how the "should_not" case is intended to behave...