I do not see anything in the Windows specific notes you linked to that documents when, or even if it tries, to distinguish shell built-in commands from external executables?

Unless you include "The capture subroutine always returns the 32-bit exit value under Windows. The capture subroutine also never uses the shell, even when passed a single argument.", which seems like a very ... um .. short-sighted policy.

Whilst there are a few specific time when you want to avoid using the shell for application specific pragmatic reasons; doing so at all times and at all costs is dogmatic and unjustifiable.

This is another of those occasions where IMO, the attempt to provide cross-platform compatibility is being applied at too low a level. The way OSs, and particularly shells, do their thing is necessarily sufficiently different, that trying to abstract at that level is bound to end in unacceptable compromises at best; and unworkable failure the rest of the time.

The alternative is that programs abstract system calls at a higher level. That is, at the 'perform this particular OS function" level:

my $resultFromExternalSource;
if( $^O eq 'MSWin32' ) {
    $resultFromExternalSource = win32GetFromExternalSource( ... );
}
elsif( $^O eq 'linux' ) {
    $resultFromExternalSource = linuxGetFromExternalSource( ... );
}
elsif( $^O eq 'VMS' ) {
    $resultFromExternalSource = ...;
}
elsif ...
[download]

The lower the level you try to abstract something at, more more likely the 'lowest-common-denominator' requirement will compromise the possibilities.