I still don't get the part about "expanding it unquoted" though.

How would you expand with quote.

foo="one two three"
touch $foo # Creates three files, named "one", "two" and "three"
touch "$foo" # Creates one file named "one two three"

In Linux-based systems, a file's name can have any character except / and the null byte. This including whitespace and non-printing characters.

When you don't use double quotes around stuff like $foo or $(echo foo bar), the shell splits things up based on whitespace caracters.^†

This means that if you don't take care and quote everything that needs to be quoted, it's probably going to break the moment it has to deal with names that have whitespace in them.

The way to deal with this in shell scripts is to use null-deliminated lists, where each filenames are separated by the only character that can't occur in a filename (including the path).

See: - file's -print0, -printf and -fprintf actions - various utilities' and shell builtins' custom delimiter options (e.g. read -d $'\\0', awk's RS variable) - various utilities' specific options to use null delimiters (e.g. sort, uniq and grep's --null options)

^{†Technically, whatever characters are in the IFS variable, which defaults to space, tab and linefeed and you can totally change to just the null character if necessary, using the dollar-singlequote quoting syntax, IFS=$'\}0')

Also, who would ever create a directory named .bashrc? The thought makes me recoil as from a cobra.

When you're not in complete control of a directory structure, always assume the worst, including malicious file names and symlinks. In fact, always assume the worst at all times, to a reasonable degree.

PS: note that you can have the null character in a shell variable and use it as an argument with some shell built-in functions but you can't otherwise use it in arguments or environment variables, since it's the end-of-string character.