Feel free to ask questions here. I'll try my best to respond to them. We're preparing for ICFP tomorrow, and my train back from Yokohama was pretty late, so I probably won't be able to answer right away.
I originally wrote/released the enumerator package because iteratees seemed really interesting, but I didn't like the function names or docs. That's it. The sole advantage enumerator has is that it's prettier.
Compare:
mapStream :: (Monad m, ListLike (s el) el, ListLike (s el') el', NullPoint (s el), LooseMap s el el') => (el -> el') -> Enumeratee (s el) (s el') m a
Map the stream: another iteratee transformer Given the stream of elements of the
type el and the function (el->el'), build a nested stream of elements of the type
el' and apply the given iteratee to it.
map :: Monad m => (ao -> ai) -> Enumeratee ao ai m b
map f applies f to each input element and feeds the
resulting outputs to the inner iteratee.
After wrestling with this since thursday, I wrote a function that's something like (wrapEnum :: Enumerator ai m b -> IO (Enumerator ao m b)), so I can convert an enumerator of one type into an enumerator of another type (I'm not looking at the code right now; that signature is obviously lacking, but it's the idea, anyhow). I think that's probably horribly wrong, but I just can't wrap my head around the type and behaviour of Enumeratees, even after reading the really pretty and simple ones that come with the snap-core package.
I think the idea is awesome, and I'm very happy about being able to use other people's Enumeratees like the various compression ones and ideas that I can express as a map or a fold, but I'm definitely missing something.
Making them return a Step allows both types of extra input to be stored, and possibly consumed later by other iteratees.
You can use (=$) or ($=) to modify how extra input is handled (by discarding it at certain points). Your wrapEnum is probably a special case of ($=).
It is extra work to use persistent's enumerator interface though.