Michael Albinus wrote:
> So I have rewitten it, and pushed it to Emacs master.
> ...
> So I exclude this special "ln -sf" call for NetBSD, such longuish file
> names shouldn't happen in the wild (I hope). See the reworked patch for
> tramp-tests.el.

With these two new files, the tramp part of "gmake check" terminates.
Find attached the log files.

> And NetBSD has restricted ressources, for example it
> reports PIPE_BUF being 512, where other systems report 4096 ...

If your code and tests depend on the value of PIPE_BUF, that explains it.
Whereas the maximum command line length (according to the libtool configure
test) is:
  checking the maximum length of command line arguments... 196608

The PIPE_BUF in POSIX [1] can be as low as 512 [2]. Here are the values
on various platforms:
  - 512 on macOS, FreeBSD, NetBSD, OpenBSD, MirBSD, native Windows.
  - 4 KiB on Linux, OSF/1, Cygwin, Haiku.
  - 5 KiB on Solaris.
  - 8 KiB on HP-UX, Plan9.
  - 10 KiB on IRIX.
  - 32 KiB on AIX, Minix.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html

> such longuish file names shouldn't happen in the wild (I hope).

But the problem is:
  - It's not only NetBSD. It's all *BSDs that have a PIPE_BUF value of 512.
  - tramp seems not only to fail in this case, but to go into an endless loop,
    which is much much worse.

Btw, I know that passing long commands through pipes is hard to implement.
A frequent mistake - that leads to endlessly hanging processes - is to leave
a file descriptor open in both the parent and the child process, when it
should only be open in one of the two.

Bruno