What are some cases that the number of spaces do matter in bash (or other shell) scripts

This is probably cheating, but this:

rm foo\ bar         # "delete the file named 'foo bar'"

is different from this:

rm foo\  bar        # "delete the files named 'foo ' and 'bar'"

even though the spaces are not in quotes. ;-)

More confoundingly, this:

rm \
    foo          # "delete the file named 'foo'"

is different from this:

rm \ 
    foo          # "delete the file named ' ', then run the command 'foo'"

even though they look identical!

Outside of quotes, the shell uses whitespace (spaces, tabs, newline, carriage-return, etc) as a word/token separator. That means:

• Things not separated by whitespace are considered to be one "word".
• Things separated by one-or-more whitespace characters are considered to be two (or more) words.

The actual number of whitespace chars between each "thing" doesn't matter, as long as there is at least one.

If we don't talk about the space character (U+0020), but any whitespace character (U+0020, \n, \t, etc.), then one particular case come to my mind: Here-Documents.

This code (using spaces):

cat <<- 'EOF'
<space><space>foo
EOF

Will print:

  foo

But this code (using tabs):

cat <<- 'EOF'
<tab><tab>foo
EOF

Will print:

foo

That's because (as POSIX states):

If the redirection operator is <<-, all leading <tab> characters shall be stripped from input lines and the line containing the trailing delimiter.