"should" sounds a bit dangerous to me. "Should be transparent" ... or so it's not always? It can fail? Or what? How? The "should" seems to cause uncertainty.

Mkay, let's see. If we declare the variable in a loop, we are about to do another iteration and there are no other references to the data, perl may clear the contents, but leave the structure (can't remember the name) and it doesn't have to allocate memory for that variable for the next iteration. Nice. Efficient. Now what does it do if it's not in any loop? Or it was the last iteration? What if it's a my variable inside a string eval""?

I believe your tutorial will only make sense if you first explain at least a bit about how are the data stored (the variable name points to a SV which points to the string/contains the number/whatever) and then you can go on explaining what's "cleared" or "freed" and what does the Devel::Peek::Dump mean.

Anyway for almost everyone the whole memory allocation tutorial should be "Declare variables with my in the tightest scope possible. Make sure you either do not create circular references, use weaken() to make sure at least one link in each circle is weak or break the circle by reseting at least one reference to undef. Do not expect perl to return the memory to the OS, but that doesn't mean the memory is not freed and will not be reused, it's just kept in perl's own hands. The rest is not your business."