What about instead of having four of these public functions, we just have one, with a boolean parameter (that defaults to true) for whether to append newline, and then a nullable onError callback parameter--if onError is null then we unconditionally call completer.completeError() with caught errors?

My concern with four functions is that contributors will cargo cult the wrong one. There's a lot of cognitive complexity here understanding the differences. In a code review also, it's difficult to parse the differences.

with a boolean parameter (that defaults to true)

If you were to rewrite the IOSink API, would you remove writeln in favor of adding a boolean parameter to write with a default? If not, why should the ProcessUtils counterpart not exist as its own function?

and then a nullable onError callback parameter--if onError is null then we unconditionally call completer.completeError() with caught errors?

is

ProcessUtils.writeToStdinUnsafe(stdin: myProcess.stdin, line: 'foo');

less readable than

ProcessUtils.writeToStdinGuarded(
  stdin: myProcess.stdin,
  line: 'foo',
  onError: null,
);

?

My concern with four functions is that contributors will cargo cult the wrong one.

How are separate named functions more cargo-cultable than fewer ones with boolean parameters (especially when one or more of those boolean parameters are optional)? Looking at the two examples I wrote earlier, is the idea that onError: null is easier to notice and think about than looking at the function name?

In a code review also, it's difficult to parse the differences.

How so? Is this something I can address with doc comments? If the diff is difficult to parse, I'd recommend just reading the code directly.

SGTM