What I see is this:

1. the final $yund is an actual undefined use caught by strict, the others instances don't try to actually use an undefined variable, consider e.g. the shift. my $tmp; $tmp and ... is fine, $tmp."1" is not.

2. probably not what surprised you, but still: man perlop, at the beginning: operator precedence of 'or' is lower than of ','. Add parens to huh4 if this is surprising: or actually has the lowest precedence of all. Another variant: perl -e 'print "a" and print "b"'

2b. use warnings stops on the use of $yund, before the open, w/o use warnings we get "No such file".

3. but what surprises me is that this doesn't happen with huh3/huh31, maybe a bit later _inside_ open. Answer:

perldoc -f open:

As a special case the 3-arg form with a read/write mode and the third 
+argument being "undef":
     open(TMP, "+>", undef) or die ...

     opens a filehandle to an anonymous temporary file.  Also using "+
+<" works for symmetry,
     but you really should consider writing something to the temporary
+ file first.  You will need
     to seek() to do the reading.
[download]

4. What does huh4 with an explicit assignment $yund=undef? Unchanged.

---

5. A bit of an annoying difference between an variable interpolation of an undefined variable vs. undef as the result of an expression other than a basic variable.

Maybe something like 'if value is from a real expression, just use it'. But if it's a variable, the argument to open does interpolation and get's the error. But I think it's a bit worse: w/o use warnings, open() in huh4 gets "" as argument (2b above; "" being the interpolated value for undef) instead of undef (3, eveything but huh4). I did not expect the extra interpolation for huh4.

Any takers for digging into the C source to point out my mis-assumptions in this explanation attempt? Thanx :)

---

Thanx to the opener for spotting this nice riddle