The rc example is worse than the first of yours. I hate the zsh special syntax in the second: it violates a deeply ingrained code feel I have about the syntax of shell code. The do ... done syntax helps the eye.

rc really shines when you have problems that in bash or zsh would suggest using multiple layers of expansion. The semantics of rc's expansion is much less thorny.

I prefer real examples - here, why not just write

    seq 1 100

- what is the loop for? And shell loops can frequently (always, if you are willing to write helper scripts) be replaced with xargs, which tends to be very much faster, e.g.

    seq 1 100 |  xargs echo

(which doesn't quite give the same output, but passing -n1 to xargs fixes that)

It's sort of ok when its `do... done`. But what about `if`..`fi` or `case`..`esac`.

+1 for rc.

Honestly, I find that stuff pretty easy to remember. And is it that ugly, in the grand scheme of ugly shell syntax? :)

I mean, what about [[ ]] vs. (( )) vs. [ ]? Or the beginning of a case statement? Those always get me since I don't use them often enough for them to stick.

[ ] is easy. It's just the 'test' command.[1]

  % which \[
  /usr/bin/[

All of the other syntax is shell-specific (run via built-ins), so that can vary, and be a little more obtuse.

[1] Albiet with some minor differences:

  % if [ -d /tmp ]; then echo "TRUE"; fi
  TRUE
  
  % if test -d /tmp ]; then echo "TRUE"; fi
  test: too many arguments
  
  % if test -d /tmp; then echo "TRUE"; fi 
  TRUE

  % diff /usr/bin/{test,\[}
  Binary files /usr/bin/test and /usr/bin/[ differ

  % man \[
  No manual entry for [

Yes. rc has less of it, fewer edge cases, etc. Even though it still has lists implemented sanely, a full set of redirects, etc:

    $ 9 man rc | wc -l
    496
    $ man bash | wc -l
    4890

Fewer interactive features as well, unfortunately. But it's small enough to keep in your head, and I find that makes it far more pleasant to use.

Even better: for i in {1..100}; echo $i