Hm, do you have any examples handy? It's not that I don't believe you, it's just that in all the years I've been using this, it has always worked. Granted, I'm only using it for reading data, not for saving stuff to /dev/stdin, which would obviously fail.

Anything that seeks, which you can't do on a pipe.

atop parsing its logfiles.

  # Cuts off partway through:
  zcat atop.log.gz | atop -r /dev/stdin | less
  # Works fine:
  zcat atop.log.gz > atop && atop -r atop | less

That said, I agree with your experience that /dev/stdin usually works for programs that read a file straight in.

`file` on BSD/OSX has this notice for the option '-s':

> Normally, file only attempts to read and determine the type of argument files which stat(2) reports are ordinary files. This prevents problems, because reading special files may have peculiar consequences.

One example that comes to mind is /dev/urandom, which sucks randomy values out of the entropy pool (at least in Linux)—and the pool can be exhausted, or at least it could back in the day, not sure about now. Other possible cases are things in /proc (though unlikely), and particularly stuff like serial ports—where presumably reading could gobble data intended for some drivers or client software.

Not the best example here, but try to open a file descriptor in VSCode. I had a scenario where I wanted to diff a file on two different servers with a user-specified diff tool, and certain ones won't even operate in a read-only manner.

Seeking doesn’t work on stdin for example. Or mmapping, I imagine

Untested, but I expect unzip will fail because it keeps metadata after the files, so needs to seek back. (Unless they detect the pipe and buffer everything instead)

fseek(3) etc, and using stat(2) to determine allocation sizes springs to mind as things you might want to do on a normal file that will not work as expected on a character device.