Along with this, we (that is, the Stonehenge folks) tell our classes that we are going to lie to them. That gets their attention, then we explain that we aren't really going to lie, but we aren't going to tell them the whole truth. For instance, we're not going to explain every dark corner of scalars before we show them how to use them. Then we tell them that when they study this more, they may run into exceptions and special cases, and we purposedly left that sort of stuff out so we got the idea across without taking two days to explain it.

People learn in spirals. They'll go over the topic several times and pick up different things on each circle, and on each circle they are not going to pick up everything. A week of training or a written tutorial is a single circle. If you put everything in those, people are just going to get confused and not pick up anything.

As Randal says, just give them the steps to get them from start to end. Don't worry about completeness---they'll get that as they gain experience. Let them know where they are going, and make sure they know the connections between the steps. Make the path clear, not just the end points.

A lot of the Stonehenge material reduces complex topics to a single sentence: "A scalar is a number or a string", "An object is a blessed reference", "A closure is an anonymous subroutine which references a lexical variable that has gone out of scope". The rest of the discussion comes back to the single sentence and spirals around it because that's what we want people to walk away knowing. They'll pick up the nuances, exceptions, and special cases with experience (or maybe the next level Stonehenge course :)

From a beginner's perspective, it's the mistakes that people want to read about. Just about everything in Perl already has a couple articles about it, and just about everything is already documented, so the only thing left is the human story. :)