POSIX compliance in no way makes environmental variables in shell scripting more usable and readable, its usually the opposite.

I say this as somebody who has written shell scripts for almost 20 years.

Constructs like

    if [ "X${str1}" = "X${str2}" ]

to avoid things exploding because a zero length variable might exist is a stupid and ugly hack.

Not to mention the hell that is trying to use a user supplied filename safely in shellscript. (for the uninitiated, a unix filename can contain any character, and any sequence of bytes besides / and 0x00, including newlines, backspaces, shell meta-charachters and so many more exciting things)

> to avoid things exploding because a zero length variable might exist is a stupid and ugly hack.

That has less to do with POSIX compliance, as opposed to working around quirks with less-compliant historical implementations. Also, I think you'd have to dig pretty deep to find a test that doesn't support zero-length arguments; you'd be safe as long as you quote your variables.

The actual problem of ambiguity arises from variables that are also syntax, like '(', or '!', when using compound expressions (which you should avoid anyway).

  # this is bad (also obsolete)
  [ "$var" != foo -a "$var" != bar ]
  # this is good (and fully POSIX compliant)
  [ "$var" != foo ] && [ "$var" != bar ]
  # you probably don't need to care for systems where this was necessary
  [ "X$var" != Xfoo ] && [ "X$var" != Xbar ]