There is sometimes a convention to have the outer next function use abort as the variable name instead of end.
e.g. the following from pull-stream-examples:

function map (mapper) {
  //a sink function: accept a source
  return function (read) {
    //but return another source!
    return function (abort, cb) {
      read(abort, function (err, data) {
        //if the stream has ended, pass that on.
        if(err) return cb(err)
        //apply a mapping to that data
        cb(null, mapper(data))
      })
    }
  }
}

or this from patchfoo:

function catchTextError() {
  return function (read) {
    var ended
    return function (abort, cb) {
      if (ended) return cb(ended)
      read(abort, function (end, data) {
        if (!end || end === true) return cb(end, data)
        ended = true
        cb(null, end.stack + '\n')
      })
    }
  }
}

Part of what makes the referenced code from pull-stream/throughts/filter harder to follow I think is that it includes protection against stack growth and callbacks potentially being called synchronously. Related: dezalgo - and the package looper mentioned by @dominic in %sBL+I3p... - or pull-looper. That is why there is a while loop in there when it could otherwise apparently be written more simply.