Escaping spaces for remote filenames passed to scp behaves incorrectly(?)

"OpenSSH for Windows" version
((Get-Item (Get-Command ssh).Source).VersionInfo.FileVersion) == 7.7.2.1 (also occurs on 8.1)

Server OperatingSystem
Linux Mint 20.1

Client OperatingSystem
Windows 10 Pro

What is failing
I'd like to copy a remote file with spaces in the name from a Linux server to a Windows client (running the command on the Windows client). However, getting the escapes right is very difficult, made worse by the relatively-new strict filename checking in OpenSSH.

I'd expect the following to work:

scp "server:~/foo\ bar.txt" .

When both the client and server are Linux, that should pass ~/foo\ bar.txt to the server to be interpreted on that end (assuming I'm understanding things correctly). However, when the client is Windows, that fails. The closest I've been able to get to work from a Windows client is scp "server:~/'foo bar.txt'" ., but that runs afoul of strict filename checking, so on newer versions of OpenSSH, I also have to pass -T to disable that check.

It would be ideal if scp "server:~/foo\ bar.txt" . worked as expected, since then, so long as the server resolves paths like *nix, it would be easy to build the correct command: start by escaping the path according to the server's rules (i.e. add a \ before the space), and then escape that according to the client's rules (e.g. wrap with quotes on Windows, double-escape the space on Linux like \\\ , etc).

Expected output

$ scp "server:~/foo\ bar.txt" .
foo bar.txt                                   100%    9    30.3KB/s   00:00

Actual output

$ scp "server:~/foo\ bar.txt" .
scp: /home/jim/foo: No such file or directory
scp: bar.txt: No such file or directory

Start by reproducing the quoted scp command on the Windows client against a Linux server, comparing it with the Linux-to-Linux behavior described. Investigate how scp parses the remote filename and verify that the escaped space is passed as one remote path without requiring -T.