v2 ideas

you asked to help maintain this library, so here are some thoughts:

• streams2 implementation, shouldn't be hard with readable-stream.
• i don't like the type inferencing in getBody. prefer if it were like .pipe(cat.string()), .pipe(cat.buffer()), etc. by default, .pipe(cat()) should just return an array of all the things. developers should know the type of source stream and how they wish to consume the data.
• delegate specific use-cases to other libraries. for example, if you want to concat to a string, just use raw-body (if we get .pipe support). overkill, but i don't feel like reimplementing the stream decoder stuff.
• add cat(stream, callback), basically just stream.pipe(this)
• callback(err, data) - it's a callback, not an event listener, so imo it should have err as the first argument. however, err should always be null since concat-stream should never have any errors (i get https://github.com/maxogden/node-concat-stream/issues/6#issuecomment-19874128) unless we decide to throw errors when there are crazy typing issues. we can do crazy stuff like check listener.length but i'm not a fan of that either.
• don't re-emit data (https://github.com/maxogden/node-concat-stream/pull/11). it doesn't handle back pressure so it's a terrible idea. people should just pipe to both cat-stream and the final stream.
• yield stream.pipe(cat()) support. not sure how to do that yet - maybe duck type it into a promise.

No files or tests are named. Start by reviewing the current cat(), getBody, and pipe behavior alongside readable-stream, then separate the proposed API changes from rejected ideas. The issue needs a chosen scope and acceptance criteria before completion can be defined.