First up. PerlIO layers are definitely a part of this problem. Commenting out the binmode makes it go away (as you already know>).

But, it is (much) more complicated than that. At the point where the unlink fails, (at least) two processes are hanging on to handles to that file:

C:\test>junk44
Permission denied : The process cannot access the file because it is b
+eing used by another process at C:\test\junk44.pl line 30.
perl.exe pid: 17320 PB-IM2525-AIO\HomeAdmin :    60: File  (RW-)   C:\
+test\ttz
cmd.exe pid: 17324 PB-IM2525-AIO\HomeAdmin :    60: File  (RW-)   C:\t
+est\ttz
handle.exe pid: 16152 PB-IM2525-AIO\HomeAdmin :    60: File  (RW-)   C
+:\test\ttz
[download]

1. perl.exe is the one running the script.
2. handle.exe is the process that is doing this discovery.
3. cmd.exe is (one of) the shell that was used to run the echo command to create the file.

   Further muddying the waters here is your prefixing the command you want to run with 'cmd /c'.

   Because the system code detects that you are using a shell metachar '>' in the command, it automatically prefixes the command you supply with 'cmd.exe /x/d/c'.

   So the actual command being run is:

   cmd.exe /x/d/c "cmd /c echo xx >$file"
   [download]

   Doing away with that doesn't fix the problem, but it makes it less complex.

Also, running the command to create the file from within the script is confusing things and there is no need for it.

This simplified version of your script:

use strict;
use warnings;

my $file='ttz';

open( my $fh, $file ) or die "open error $!";
binmode( $fh, ':unix');

close($fh) or die "close error $!";

if( !unlink($file) ) {
    warn $!, ' : ', $^E;
}
[download]

exhibits exactly the same behaviour when the file is pre-created:

## In a different session from which I will run my modified version of
+ your script
C:\test>echo xx > ttz
C:\test>handle | find "ttz"  ## shows that immediately after creation,
+ nothing has an open handle to that file

## Now in the other session
C:\test>junk44
Permission denied : The process cannot access the file because it is b
+eing used by another process at C:\test\junk44.pl line 12.

## And back in the first session whilst the 10 second sleep is running
C:\test>handle | find "ttz"
   60: File  (RW-)   C:\test\ttz
[download]

Only one process has a handle to the file, and that process is Perl itself.

(Tentative) Conclusion: The error message is wrong, or at least, misleading. The "other process" that is preventing the unlink, is actually the same process that is trying to perform the unlink.

Essentially, the close has failed (silently), or has simply not been enacted, and so the unlink cannot proceed because there is an open handle to the file.

Tracking this further means delving into IO layers ... why did the close fail silently?