Note that the Tie::File docs do not say here (or anywhere else) that changes to the file will be reflected in the array immediately. Tie::File may be capable of following additions to a ever-growing file, but that really doesn't appear to be one of the tasks it was designed to handle.

A couple more relevant bits from the locking section of the Tie::File docs are

When you use flock to lock the file, Tie::File assumes that the read cache is no longer trustworthy, because another process might have modified the file since the last time it was read. Therefore, a successful call to flock discards the contents of the read cache and the internal record offset table.

and

The best way to unlock a file is to discard the object and untie the array.

To me, these indicate that, if the underlying file is changed, then Tie::File will have to rebuild its table of record offsets, which means starting over from the beginning of the file and reading every line until it reaches the one you're looking for (i.e., the one that was just added to the end of the file), which is exactly the sort of re-scan we're trying to avoid here.