> successful

As in not throwing exception or as in evaluates to true?

> exit code is > 0

You refused to get into specific exit codes for specific programs citing potentially surprising behavior (which I agree will sometimes be an issue).

> STDERR in ('false', 'no', 'off', 'fail', 'failed')

I correlated this with the following source code:

> if len(s) == 0 || s == "null" || s == "0" || s == "false" || s == "no" || s == "off" || s == "fail" || s == "failed" || s == "disabled" { return false

... which also has a potential for surprising behavior. (side note: appears to work on stdout, not stderr)

> or []byte(STDERR) > []byte(STDOUT)

Does that mean len(stderr) > len(stdout) ?

... also has a potential for surprising behavior. I can easily imagine a program with lots of debug/warnings/log on stderr and truthy/non-error output.

> STDERR messages are useful for functions that return a message rather than exit code.

Might be problematic because typically exit codes are used for that.

> where `if` is evaluating the result of `which` and you don't need to do more complex tests like you would in Bash to test the output of `which`.

Mmm.. Never did this. In which situation looking just at exit code of `which` is not good enough?

> if { which: foobar } else { err: "foobar is not installed }

Just to show off :) in NGS that would be:

    if not(Program('foobar')) {
        error("foobar is not installed")
    }

or sometimes just

    assert(Program('foobar'))