It's fine for it to return nil when the command is not found. It's falsy.

Sorry but It seems not ok to me
If 'command' is not found returns falsy, but in this situation routine is unable to find 'tool'

I don't understand the concern you're raising:

irb(main):001> system "command -v yarn > /dev/null"
=> true
irb(main):002> system "command -v yorn > /dev/null"
=> false

'command' is a shell (sh) command
If you execute irb not in a shell but in windows CMD or kind of different terminals, the result will be always falsy, for error 'command not found' referred to 'command' itself

Instead 'which' is an external command, often installed at system level (is an executable in PATH) in both Linux, Windows etc

Ah, I see. So you're hitting this problem running it in a Windows shell? Does the rest of everything work otherwise? We typically don't spend much/any time on compatibility with Windows shell, since WSL offers a much easier road to compatibility. Or is there another shell where this is manifesting itself?

Also in linux
See these screens
WSL2 - Ubuntu

Real linux - Debian

Both have same problem
My opinion: IRB does not spawn on the sh shell who launched it (it's a different process? standalone executable? don't know),