Отличия STDIN дочернего процесса Windows / Linux

Я создал простой скрипт обработки текста на работе, который будет использоваться другой программой. Когда я закончил, кто-то вспомнил, что скрипт не должен блокировать STDIN / STDOUT, чтобы инструмент, использующий его, работал правильно, и изменил скрипт соответствующим образом. Скрипт открывает cat * nix в подпроцессе через IPC::Open2 и печатает в него STDIN, читает его обратно. а затем обрабатывает и распечатывает его в STDOUT. Я понятия не имею, как это делает скрипт неблокирующим, но, видимо, он работал.

Я хотел, чтобы она работала и в Windows, поэтому заменил cat на type CON, простую команду Windows для печати STDIN. Ниже приведен пример сценария:

use strict;
use warnings;
use IO::Handle;
use IPC::Open2;

my $command = ($^O eq 'MSWin32') ? 'type CON' : 'cat';

my ( $com_reader, $com_writer ) = ( IO::Handle->new, IO::Handle->new );
open2( $com_reader, $com_writer, $command );
# input
while (<STDIN>) {
    print "first line: $_";
    print $com_writer "$_";
    my $line = <$com_reader>;
    # ...process $line...

    print "next line: $line";
}

Однако результаты совсем другие. В Windows потоки STDIN для основного сценария и дочернего сценария кажутся разными, в то время как в Linux они одинаковы. В Windows (я набираю 1 и 2 на отдельных строках ввода):

>perl test.pl
>1
first line: 1
>2
next line: 2
>1
>2
first line: 2
next line: 1
>1
>2
first line: 2
next line: 1
>1
>2
first line: 2
next line: 1

В Linux (тот же ввод):

>perl test.pl
>1
first line: 1
next line: 1
>2
first line: 2
next line: 2
>1
first line: 1
next line: 1
>2
first line: 2
next line: 2

Почему результат отличается, и как я могу заставить поведение Windows соответствовать поведению Linux? Кроме того, почему этот трюк «открыть кота в подпроцессе и передать его через конвейер» вообще работает?