Right. The problem occurs when running a session in a pseudo tty like
when starting GDB in a ssh session or when you set CYGWIN=tty before
starting the first Cygwin process (the shell, usually) in a Windows
console window.
Pseudo ttys are implemented in Cygwin using pipes. When you start a
Cygwin application with fork/exec, the knowledge about this pipes (being
a pseudo tty) is inherited by the child process by means of the fork/
exec magic.
If you start a Cygwin process from another application using native
Windows functions (CreateProcess, etc), the whole fork/exec magic is
missing, apparently. One result is that the child process has to
figure out what the stdin/out/err streams are, using native Windows
functions. Since native Windows functions have no idea what a pseudo
tty is, the information returned is that stdio streams are connected
to pipes. So the child thinks its stdio streams are just pipes and
pipes are not ttys, apparently.