If the spec ended on this line, we'd have a scenario where `beforeChange` is called, but `change` is never called. That is, it's no longer guaranteed that `beforeChange` will always be followed by `change`, no matter how long you wait.

In a sense this is kind of breaking, in that some code in the wild (let's say, on the project I currently work on, for example :) ) relies on `beforeChange` always being paired with `change`. However that code should never have made it into the project because there was never a guarantee that someone who calls `valueWillMutate` will go on to call `valueHasMutated`.

Let's be sure to amend the docs to emphasise that `beforeChange` does not in any way guarantee that there will be a subsequent `change`, since it's up to the person raising these events to issue them in pairs if they want to, and in particular, `rateLimit`ed observables will find their `beforeChange` and `change` events typically separated in time.