I believe that something is simply broken in the OS. Granted, these are custom ROMs, but I have tried several different ones, and the interrupted system call thing is the case in all of them. The last official version of Android for this device is Android 4.1, and there everything seems to work fine, at least as far as filesystem operations go. The problem is that I need to run 1 application, which requires Android 4.4 and later, so I cannot stay on the old Android because of it.
The panics are not that often though. As long as there is not much filesystem activity, Syncthing seems to stay up and running for long time, e.g. 1d 7h 40m right now. Also, as long as Syncthing manages to restart itself after these panics, and there are no file corruptions (and there has been none so far), I will likely just keep using it this way.
This has been a change in the go runtime. Previously it used to hide and retry a bunch of these interrupted calls, it no longer does. You can try to compile yoour own version with an old version of go, but we’re definately not going to use an outdated version of go just to support outdated phone versions.
A consequence of the implementation of preemption is that on Unix systems, including Linux and macOS systems, programs built with Go 1.14 will receive more signals than programs built with earlier releases. This means that programs that use packages like syscall or golang.org/x/sys/unix will see more slow system calls fail with EINTR errors. Those programs will have to handle those errors in some way, most likely looping to try the system call again. For more information about this see man 7 signal for Linux systems or similar documentation for other systems.