The most direct reason for removing them is that they allow users to witness a
violation of the following `MonadTrans` law:
lift (return x) = return x
Here's the proof:
>>> toListM (lift (return ()) `mplus` yield 1) :: [[Int]]
[[],[1]]
>>> toListM (return () `mplus` yield 1) :: [[Int]]
[[]]
Those two should return the same result, because `lift (return ())` should equal
`return ()`, but they do not.
I also haven't proven that these instances obey the associativity and identity laws
for `Alternative`/`MonadPlus` (and I suspect they don't)

Older versions of `pipes-safe` also provides a `MonadThrow` and `MonadCatch`
instance for `Proxy`, but they have a `pipes < 4.3` bound. In order to avoid
incompatibility between the two libraries the plan is to:
* Increase the `pipes` version to `4.3.0`
* Release a new `pipes-safe` version with a `pipes >= 4.3.0` constraint
This ensures that the two libraries will never have a build failure when built
together. At worst they might incur a dependency resolution failure

`criterion` and `test-framework` do not mix well with each other on `ghc-7.6`.
The issue is that:
* `ghc-7.6` comes with `bytestring-0.10.0.2` installed by default
* `ghc-7.6` also comes with a `regex-posix` built against `bytestring-0.10.0.2`
* `criterion` requires a version of `bytestring` newer than `0.10.0.2` due to a
dependency on `aeson`
* `test-framework` requires `regex-posix`
This leads to one of two problems when building both the benchmark suite and the
test suite at the same time for `ghc-7.6`. Either:
* older versions of `cabal` fail at build time because they select the following
invalid plan:
* pick a `semigroups` library built against `bytestring-0.10.02` that is
missing a `Semigroup` instance for `Data.ByteString.Builder.Builder`
(this instance is only provided when building against newer versions of
`bytestring`)
* pick an `aeson` library built against `bytestring-0.10.8.1` that expects
a `Semigroup` instance for `Data.ByteString.Builder.Builder`
* newer versions of `cabal` fail at plan time because they refuse to have two
different versions of `bytestring` in the same build plan
My workaround for now is to disable building benchmarks in Travis. I will
re-enable building benchmarks once I phase out support for `ghc-7.6.3` (which
in turn will happen when Debian Stable ships a newer `ghc` version)