Okay, that makes sense. However, I just tried to create errors by deleting a) a non-existant subdir. b) a subdir which I did not have permission to delete. I tried this using eval as shown in your post and again in neither case did anything end up in $@. I did get various messages to STDERR:

Can't make directory testtesttest read+writeable: Permission denied at
+ C:\test\QOTW\test.pl line 27
Can't read testtesttest: Invalid argument at C:\test\QOTW\test.pl line
+ 27
Can't make directory testtesttest writeable: Permission denied at C:\t
+est\QOTW\test.pl line 27
Can't remove directory testtesttest: Permission denied at C:\test\QOTW
+\test.pl line 27
and can't restore permissions to 0777
Should be no errors
$!: 'Permission denied'
$@: ''
Can't make directory testtesttest read+writeable: Permission denied at
+ C:\test\QOTW\test.pl line 31
Can't read testtesttest: Invalid argument at C:\test\QOTW\test.pl line
+ 31
Can't make directory testtesttest writeable: Permission denied at C:\t
+est\QOTW\test.pl line 31
Can't remove directory testtesttest: Permission denied at C:\test\QOTW
+\test.pl line 31
and can't restore permissions to 0777
Should be errors
$!: 'Permission denied'
$@: ''
[download]

Looking at the docs I saw this:

Note also that the occurrence of errors in rmtree can be determined only by trapping diagnostic messages using $SIG{__WARN__}; it is not apparent from the return value.