FWIW, in a tight for loop of a million executions of either test 1, [[ 1 ]], true, or :, I get: test 1 -> 2.70s true -> 2.55s : -> 2.25s [[ 1 ]] -> 2.10s Like

FWIW, in a tight for loop of a million executions of either test 1, [[ 1 ]], true, or :, I get: test 1 -> 2.70s true -> 2.55s : -> 2.25s [[ 1 ]] -> 2.10s Like, I don't even have a way to measure the overhead of just the for loop as [[ is faster than that. But we can do something and see the cost of that: let's do a -z $a when a=. We don't need to quote the $a with [[, but I'll do it both ways: test -z "$a" -> 3.25s [[ -z "$a" ]] -> 2.65s [[ -z $a ]] -> 2.10s So, sure: it isn't a performance difference that is likely to kill a use case, but it does exist. I also agree that it isn't necessarily worth bothering with... but I just can't get behind something -- using test -- that is both slower and more complex... like, to me, it isn't [[ that has "functionality" that I might not need, it is test: with test I can programmatically decide operators by putting them in variables, while with [[ everything must be syntax. This is an incredible amount of extra power that you get with test that I frankly don't just not need... I actively would prefer not having except in a scant handful of scenarios. It is much easier to glance at a use of [[ and know 100% for sure what it is doing than with test, where you must carefully consider all of the quoting rules, and even then the behavior might be dynamic.