Considering how many people get messed up over split's first argument, I figured the extra clarification of using // over "" is warranted,

I note that you are concentrating on split which I didn't use above, (but admit I do use in the way you are indicating), rather than the $scalar1 =~ $scalar2 which I rarely use, but did use above. Mostly because I forgot to change it when c&ping the OPs code. No matter, back to the split issue.

I have made the mistake of typing split '|', $string; a couple of times. A long while since I think, but again, no matter. When I did this it was not because I forgot that the first parameter to split was a regex, but because I forgot (momentarially) that | was a meta character. And in that way, using /|/ is (again) identical. With identical result.

If there is any pretence here, it is the pretence that using // is somehow magical. It isn't. In all cases, using a scalar constant or scalar variable, or even a function returning a scalar, as the RHS side of the =~ is identical to using // or m"" or m//. The same code is generated, and the same results (good or erroneous) are obtained. There is, as far as I have discovered, exactly one situation when using // (or preferably m""!) yields different results to "", and it has nothing to do with split.

[0] Perl> sub test{ print "'$_[0]' ",  ref \$_[ 0] };;

[0] Perl> test( '|' );;
'|'  SCALAR

[0] Perl> test( m/|/ );;
Use of uninitialized value in pattern match (m//) at (eval 9) line 1
'1'  SCALAR

[0] Perl> test( /|/ );;
Use of uninitialized value in pattern match (m//) at (eval 10) line 1
'1'  SCALAR
[download]

Ie. When used in the absence of =~, a "regex" is implicitly applied to $_. But, this is not the case when it is used as an argument to split. This is another of those built-in behaviours that is impossible to emulate with a user defined function.

Personally, I think it is far better to get bitten by the difference a time or two early on, learn to appreciate the reality and integrate it into your thinking than to blithely ignore that reality and get bitten by it later. I think that 'protecting' newbies, by hiding Perl's warts is counter-productive and comes back to haunt them later.

Lessons learned by making your own mistakes, penetrate deeper and last far longer than those learnt by rote. And far, far longer than those imposed by edict. Or those never learnt at all, because you were protected from ever encountering them in your early days, when such mistakes are considered par for the course and expected.

Those unlearnt or unappreciated lessons are the ones that come back to bite you later, at points in time when they do much more harm. Perl has warts. Hiding them does not make them go away. Better to get to know them and appreciate them--the good and bad--than pretend that they do not exist.