Write to StdOutput/StdError stream should never blocks LINQPad running

For following code:

void Main1() // Hit Alt+Shift+1 to run
{
    Console.WriteLine("Test std-output");
    using Stream stream = Console.OpenStandardOutput();
    WriteStream(stream);
}

void Main2() // Hit Alt+Shift+2 to run
{
    Console.WriteLine("Test std-error");
    using Stream stream = Console.OpenStandardError();
    WriteStream(stream);
}

void WriteStream(Stream stream)
{
    stream.Write(Encoding.Unicode.GetBytes(new string('A', 2047))); // 2047, OK
    Console.WriteLine("2047 OK");
    stream.Write(Encoding.Unicode.GetBytes(new string('A', 1))); // 2048, OK
    Console.WriteLine("2048 OK");
    stream.Write(Encoding.Unicode.GetBytes(new string('A', 1))); // 2049, Blocks NOT OK
    Console.WriteLine("2049 NOT OK");
}

These 2 actions blocks LINQPad scripts running forever, I believe this should be not a expected behavior. Especially in scenarios that calls native library such as FFmpeg/x264, which uses fputs(str, stdout) for example.

(I'm not asking to redirect StdOutput/StdError into LINQPad result window, there might be some technical difficulties, I'm asking LINQPad not been blocked/deadlocked by these seems "normal" actions)

This could be the major different between LINQPad and Visual Studio in my working scenario, I took a lot of time and finally identified the issue, please take some time and try fix it ASAP.

LINQPad version: LINQPad 6.10.11(X64) Beta -Fx=5.0.0-rc.1.20452.2
I tried LINQPad 5, looks like the buffer is 4096 instead of 2048, but also blocks.