What is so great about Unix sockets that e.g. a normal TCP socket bound to localhost or even a named pipe can not do properly?

The server can get the calling process info [0], which may be useful for local access control. TCP sockets cannot distinguish clients like that.

[0]: https://docs.rs/tokio/latest/tokio/net/struct.UnixStream.htm...

UNIX Sockets are more flexible than named pipes;

* You can use them for more than two processes communicating (eg. a server process with potentially multiple client processes connecting);

* They are bidirectional;

* They support passing kernel-verified UID / GID credentials between processes;

* They support passing file descriptors between processes;

* They support packet and sequenced packet modes.

TCP only grants you 2 of these extra features (sequenced packet mode/bidirection), leaving a giant hole in security in the process.

The named pipes, at least on Windows, also support all of that except for passing UID/GID and file handles.

AFAIR you can choose to use Windows OpenSSH or the other one during Git for Windows installation. [0]

[0]: https://duckduckgo.com/?q=git+for+Windows+openssh&t=fpas&iax...

Unfortunately it's difficult to enforce that, so dealing with users who've already set things up in a specific way is a problem

could always ship a static linked ssh_client