It does not sacrifice sub-shell syntax: it is fully supported, I just had to rename it from ( ... ) to [ ... ] to avoid conflicts with ( ... ) that switches to lisp syntax

Also, both $(...) and `...` shell interpolation are fully supported.

The only thing I intentionally sacrificed is shell flow control: schemesh shell syntax does not have the builtins 'case' 'for' 'if' 'while' etc.

In practically all examples I tried, escaping to Scheme for loops and conditional code works better: it avoids the usual pitfalls related to shell string splitting, and usually results in more readable code too, at least for a Lisper

Note: there's also some additional parsing logic to distinguish between sub-shell syntax [ ... ] and wildcard patterns that use [ ... ] as well

Then [ shadows the sh executable aliased from ‘test’ so that you can no longer do

  [ some conditional ] && ...

But have to write

  test some conditional && ...

That's true.

In shells, "test" and "[" are often used after "if", as for example

  if test -f "some_file"
    do_something
  fi

  if [ "$FOO" != "" ]
    do_something_else
  fi

Schemesh does not have a shell builtin "if", you switch to Scheme for that:

  (if (file-regular? "some_file')
    (sh-run {do_something}))

Thus the need for "test" and its alias "[" is reduced.

Also, "test" implements a mini-language full of one-letter operators: `-f FILE` `COND1 -a COND2` `COND1 -o COND2` etc.

I really don't miss it, as I find the equivalent in Scheme to be more readable - and of course more general

  (file-regular? "FILE")
  (and COND1 COND2)
  (or COND1 COND2)

etc.