By opposite facing information preservation law, I mean there is a law right now called Information Preservation in the haddocks for the class.
It only supplies half the story about how uncurry mzip and munzip are "almost inverses", but the law given in the haddocks is actually pretty weird.
The nice law I mentioned 'uncurry mzip . munzip = id' says uncurry mzip 'retracts' munzip in category theoretic terms.
The existing law is kind of abomination that tries to imply that if you have the same shape on both sides they should zip together in a way that unzips without destroying or creating any weird new shapes, but without the retraction law I don't think you can prove that you've ruled out all the wonky instances.
As for what I have against munzip as a member, it is a boring, unnecessary member with no interesting definitions. It has to be equivalent to
fmap fst &&& fmap snd to pass the laws and free theorems involved.
The
only interesting instance I've ever derived is one I came up with for a memoizing variant of Lindsey Kuper's idempotent Par monad that admits pure LVar reads, and lacks region parameters. There you could exploit idempotence to reuse the results and share
some computation effort in case you use <*> to glue the parts you munzipped back together, but I don't exactly see people lining up to use it. ;) As a pure computation you need to make a new promise/IVar, fill it with the computation that will produce the (a,b) pair. Then return two computations that each demand the result of the promise when run and fmap fst or fmap snd the result appropriately.
But building that one interesting monad requires embracing at least unsafeInterleaveST levels of evil, and the instance requires upgrading that to unsafePerformST levels of messiness.
-Edward