Using a 2.4.21-4.ELsmp I'm unable to reproduce the bug
Here is what I'm doing:
pro3# mount ppro1:/home /mnt/ppro1/home
pro3$ cd /mnt/ppro1/home/tmp
pro3$ touch foo1
pro3$ rename foo foo0 foo?
pro3$ tar cvf /tmp/tar.tar foo01
foo01
pro3$ 

It looks like the customer used perl's builtin rename() function, rather than /usr/bin/rename. 
Could be that they handle file attributes differently? 

[dhoward@porkchop 28730]$ mkdir foo 
[dhoward@porkchop 28730]$ cvs co rh-rpms/kernel-2.4 
[dhoward@porkchop 28730]$ rename rh-rpms/kernel-2.4/ foo/ rh-rpms/kernel-2.4/* 
[dhoward@porkchop 28730]$ tar cvf foo.tar.gz foo 
foo/ 
foo/COPYING.modules 
tar: foo/COPYING.modules: file changed as we read it 
foo/CVS/ 
foo/CVS/Root 
foo/CVS/Repository 
foo/CVS/Entries 
foo/CVS/Entries.Log 
foo/Makefile 
tar: foo/Makefile: file changed as we read it 
foo/Makefile.config 
tar: foo/Makefile.config: file changed as we read it 
foo/Makefile.defs 
tar: foo/Makefile.defs: file changed as we read it 
foo/Makefile.project 
tar: foo/Makefile.project: file changed as we read it 
foo/Makefile.project-example 
... 

A couple of notes from the customer:

Yet another data point for what it's worth.  I have reproduced the
same issue with Arjan's 2.6 test kernel rpm (2.6.0-0.test9.1.67).  I
booted the kernel on RHEL3.

<snip>

I looked into this problem a bit further.  It doesn't look like the
CTO patches are the cause since 2.6 lacks them.  However, both kernels
have the READDIRPLUS patch which introduces a separate attribute cache
that is not updated when operations are performed on an open file. 
The relevant routine is dir.c:nfs_cached_lookup() in both kernels.  I
believe this is the source of our troubles.  It would also explain
Frank's observation that NFSv2 does not exhibit the inconsistency
since READDIRPLUS does not exist in v2.  Below is a short perl script
that reproduces the problem.  This is very close to the way tar does
the ctime check.  The script fails reliably on the very first
comparision of ctime.  The stat("junk") is presumably going through
the READDIRPLUS attribute cache whereas stat(F) is using the inode cache.

#!/usr/bin/perl -w

use strict;

unlink("junk");
open(F, ">junk");
open(X, "/etc/redhat-release");
while (<X>) {
   print F $_;
}
close(X);
my $prev_ctime = (stat("junk"))[10];
for (my $i = 0; $i < 60; $i++) {
   sleep 1;
   open(F, "junk");
   my $ctime = (stat(F))[10];
   if ($ctime != $prev_ctime) {
       print "$i: $ctime != $prev_ctime\n";
       exit;
   }
}

So is this now fixed in both RHEL3 and the latest errata from RHEL2.1?

UPDATE!

I went to ABC with a setup of test environment used
"kernel-smp-2.4.21-6.EL.i686.rpm" but that didn't solve the issue.
The symptom got reproduced.

I may suggest them to test with kernel-smp-2.4.21-7.EL.i686.rpm and
see what happens.

David, 

Could you please post a ethereal trace of the this problem... 

The issue at ABC is different from what is reported in this ticket.  
ABC's issue shows up under both v2 and v3. It appears to be related 
to timestamp resolution and asynchronous update/read of files. 
 
If I can reproduce what they report I'll open a seperate bugzilla. 
 
I can't reproduce this issue. The test case appears to be fixed. 
 
 

An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2004-017.html