Well, I was able to *find* the <INPUT> bug, but i was not able to *spot* it. So, what I will meditate on briefly is *finding* (slow) versus *spotting* (fast).
What I did: run the code with some test data, run it, look up $/ in perlvar, realize that's not the problem, read the code again, and finally realize the problem. Total time, maybe five minutes.

So, in this case, the perlish var threw me off. If the code had been written

#!/usr/bin/perl

use strict;
use warnings;
use English;

my $file = shift || die "No file, dummy!";
open FH, "<", $file or die "Could not open ($file) for reading: $!";
local $INPUT_RECORD_SEPARATOR = "\n.\n";

while (defined (my $record = <FH>)) {
    chomp $record;
    print $record;
    <STDIN>;
}
[download]

I probably would have spotted it a lot faster. So maybe the "best practices" moral here would be to use English when doing this kind of magic thing. Even if you're a perlvar wiz, the guy maintaining your code may not be.

The second moral of the story is, with regards to finding versus spotting: if you've got a short little chunk of code like this and you know it's got a bug in it, read through every line. Read the first line. Think about it. Read the next line. Think about it. Until you've read every line. Seems like an obvious thing to do, but I am not in the habit of doing it. I am in the habit of write, try it out, check for bugs. I don't usually write then check for bugs.

But of the two morals, I think use English would probably save more time in the grand scheme of things. I may put this on my list of best practices now for everything other than $_. (I wonder whether damian conway mentioned the subject in his book?)