It all depends on your stack. I think of a full-stack programmer as someone who can dive into any level of the application to fix something. If you have a classic app that is javascript in the front, PHP in the back, then he will need to be familiar with at least those two technologies.

If you are building on external technologies, like a classic LAMP stack, then it helps to know a bit about those, too. Because software has bugs, and sometimes that bug is in apache, in PHP itself, in the PHP memcache library, or in MySQL. And woe be unto you if you are the first person to run into that bug, because congratulations, now you get to diagnose and fix it. Especially if it's open source. If it's proprietary code, you're in a whole other terrible mess.

The more complex the technology stack that you are building on, the more likely that it has crippling bugs, and the less likely that you're still able to figure them out. So in some sense, there is a rationale for building my own NoSQL store: I understand every part of my stack, and I know how to debug it if it should go wrong.

Those who can (or employed to) do everything from wire crimping, kernel hacking, to UX and graphic design.

Isn't "full-stack" just a new(ish) word for systems programmer? I.e. a programmer who can reason about and optimize for what goes on on the hardware?

I've always thought "full-stack" meant both front-end and back-end. Meaning that they could work on the website and the API.