Hit tab again (without typing anything into the lower-left Entry): focus moves back to the upper-left, and the lower-left validation gets called once. Using just the tab key, you bounce back and forth between the two left-hand Entries, and with each focus change, the validation for the Entry you're leaving gets called just once. (UPDATE: What golux said above about the right-hand Entries being disabled on start-up explains why focus only bounces between the two left-hand Entries.)

Now, when you type something into a left-hand Entry before hitting tab, the tab moves focus to the other left-hand Entry, and validation runs once on the Entry where you just typed something in. Because there's content, your validation script for this widget (which doesn't have focus now) moves the focus to its associated right-hand widget.This step causes a second "focusout" event, but this time it's triggered on the other left-hand widget (the one that actually had focus when the validation function started). (UPDATE: Of course, once there is content in a left-hand Entry, its right-hand Entry becomes active, and this changes how focus moves when using the tab character.)

In effect, the way the OP code is set up, whenever focus leaves a non-empty left-hand widget, validation gets run on both left-hand widgets: the first is triggered by the "focusout" caused at the keyboard for one of them (shifting focus to the other), and then the validation forces a "focusout" on the other.

Is there some compelling reason why two pairs of Entries need to be used in combination this way? If you handled just one password_entry + password_confirmation pair, you wouldn't have this problem.

graff - you have described the way it works perfectly. I should have included it in the original post. You also pinpointed the issue, namely a second focusout was happening when leaving $entryThree, even though it was never seen while running the GUI. Thank you

You're getting a double callback because of this line in your code:

    $f2 -> focus;
[download]

Don't do that; it's triggering a focusout event on $f2, causing $f2 to enter its validation callback.

Note too, the first time you validate on $entryOne or $entryThree the corresponding column 2 Entry widget $entryTwo or $entryFour will not have been selectable, so the focus will skip to the other first-column Entry widget. If this isn't what you want, you could change the disabled states to readonly instead, because according to the Entry widget docs:

Switch: -state
... If the entry is readonly, then the value may not be changed using 
+widget commands and no insertion cursor will be displayed, even if th
+e input focus is in the widget; the contents of the widget may still 
+be selected. If the entry is disabled, the value may not be changed, 
+no insertion cursor will be displayed, the contents will not be selec
+table, ...
[download]

Finally, a suggestion (which you are free to take as you will). I find it useful to simplify Tk code by writing subroutines that consolidate common values. Since you're creating 4 Entry widgets with the same validation method, and your validation calls the same 2 subroutine, why not extrapolate that to the 2 new subroutines (here called entry and config_validate):

#!C:\Windows\Config\UMS_Scripts\perl\bin\perl
use strict;
use warnings;
use Tk;
my $globalVar = 0;

#################
## Subroutines ##
#################
sub first {
    my ($f1, $f2) = @_;
    $globalVar = $globalVar + 1;
    print "in sub first for the $globalVar time\n";
    my $count = 1;
    for my $anArg (@_) {
        if (defined $anArg) {
            print "$count - $anArg\n";
        } else {
            print "$count\n";
           }
        $count = $count + 1;
    }
    my $value1 = $f1 -> get();
    my $length1 = length $value1;
    print "value1: $value1 :$length1\n";
    my $value2 = $f2 -> get();
    my $length2 = length $value2;
    print "value2: $value2 :$length2\n";
    if ($length1 > 0) {
        $f2 -> configure(-state=>'normal');
        ## Don't do this -- it invoke the focusout event prematurely
        # $f2 -> focus;
        # $f2 -> update;
    } else {
    }
}


sub second {
   my ($f1, $f2) = @_;
   print "in sub second\n";
   ## You probably don't need this -- unused in this subroutine
   # $globalVar = $globalVar + 1;
   my $count = 1;
   for my $anArg (@_) {
      if (defined $anArg) {
         print "$count - $anArg\n";
      } else {
         print "$count\n";
      }
      $count = $count + 1;
   }
   my $value1 = $f1 -> get();
   my $length1 = length $value1;
   print "value1: $value1 :$length1\n";
   my $value2 = $f2 -> get();
   my $length2 = length $value2;
   print "value2: $value2 :$length2\n";
}


##################
## Main Program ##
##################
my $Mw = MainWindow->new(-title=>'Collecting Passwords');

my $entryOne   = entry($Mw, 0, 0, "normal");
my $entryTwo   = entry($Mw, 0, 1, "disabled");
my $entryThree = entry($Mw, 1, 0, "normal");
my $entryFour  = entry($Mw, 1, 1, "disabled");

config_validate($entryOne,   $entryTwo);
config_validate($entryThree, $entryFour);

MainLoop;


#####################
## New Subroutines ##
#####################
sub entry {
    my ($parent, $row, $col, $state) = @_;
    my $entry = $parent->Entry(-validate => 'focusout');
    $entry->grid(-row => $row, -column => $col);
    $entry->configure(-state => $state);
    return $entry;
}


sub config_validate {
    my ($ent_A, $ent_B) = @_;
    $ent_A->configure(-validatecommand => sub { first($ent_A, $ent_B) 
+});
    $ent_B->configure(-validatecommand => sub { second($ent_A, $ent_B)
+ });
}
[download]

Again, you're free to take it or leave it, but I find the simplification makes a Tk program a lot easier to read. Plus, you can easily see where to change the 2 occurrences of "disabled" to "readonly", to see the resulting effect.

Good luck!

Update:   Removed some parameters left over from debugging the root cause of the problem.

Update 2:   Link directly to description of State in the Tk docs for the Entry widget.

golux - Switching the initial state to readonly has made the code work as I would like it to. Thank you. The readonly state is not documented in "Mastering perl/Tk". It had a state of "active", which does not work. Lesson learned. I need to always check online for the latest documentation.

As for the subroutine changes, they make sense. I just have not gotten that far in the coding to come up with it. I was thinking of making a mega widget that would have a password entry, conformation entry and a visual queue for when things were correct or not.

What am I doing wrong?

You're not performing validation in a validatecommand -- why?

The code to validate the entries was removed for debugging purposes and brevity of the posting. Only the argument list and the get methods are in the original code.