There seems to be a race between MakeWindow selecting the master side and the ForkWindow opening the slave side.

On NetBSD (HAVE_SVR4_PTYS):

$ screen -S test -c /dev/null -ln -d -m -p 0 sh; sleep 1; screen -S test -X quit
No screen session found.

The command sometimes succeeds in creating a session and sometimes not.  When it fails to create a session, the SCREEN.$$ debug log contains

 + hit ev fd 5 type 1!
going to read from window fd 5
Window 0: EOF (errno 0) - killing window

As far as I can tell what happens that the parent calls select on the master fd while the child still has not opened the slave side.  NetBSD select/poll report the fd as readable and the read returns EOF.

Here's a bit of ktrace from a failed attempt:

$ kdump | sed -n -e '/select/p' -e '/EOF/p' \
                 -e '/\/dev\/pts/{' -e 'N' -e '/open/p' -e '}'
  4831   4831 screen   CALL  __select50(0x100,0x7f7fff3739f0,0x7f7fff373a10,0,0)
  4831   4831 screen   RET   __select50 1
       "Window 0: EOF (errno 0) - killing window\n"
  5218   5218 screen   NAMI  "/dev/pts/7"
  5218   5218 screen   RET   open 0

vs. a successful one:

 19165  19165 screen   CALL  __select50(0x100,0x7f7fff30a910,0x7f7fff30a930,0,0)
 26839  26839 screen   NAMI  "/dev/pts/7"
 26839  26839 screen   RET   open 0
 19165  19165 screen   RET   __select50 1
       "serv_select_fn called\n"
 19165  19165 screen   CALL  __select50(0x100,0x7f7fff30a910,0x7f7fff30a930,0,0)
 19165  19165 screen   RET   __select50 1

Using brute-force and setting pty_preopen = 1; in OpenPTY seems to fix it as the slave side is now always open already when the parent selects on the master fd.