I can confirm that the Linux VGA console does handle scroll-lock specially. I switched to a text console on my GNU/Linux desktop, and
ran cat. (bash keeps the tty in raw mode, and does its own buffering, but when the shell spawns cat, it puts the tty in cooked line-buffered mode, where the OS handles the line buffering. But one of these days GNU cat will probably use readline too…
Normally, you type a line, and you see it as you type. When you press return, cat reads it from the terminal and prints it again. Pressing ^S or scroll-lock stops typed characters from appearing on the screen. Unlike with software flow control on e.g. a modem line, the characters don’t appear after you turn off scroll lock (by pressing ^q or scroll lock). They’re still in the input buffer, though; Pressing return will give the whole line, including what you typed while scroll-lock was on. (^S and ^Q are of course the xon/xoff software flow control characters.)
One can disable software flow control by running:
stty stop undef
stty start undef
Now, pressing ^S and ^Q had no special effects; The control characters showed up on the input line. However, even with no start and stop character defined, scroll lock had the same effect as before.
stty -ixon -ixoff
still didn’t stop scroll lock from having the same effect.
BTW, processes writing to the terminal block when scroll-lock is on. According to ps, WCHAN == write_chan. The kernel source code (in drivers/char/n_tty.c) indicates that write_chan will return EAGAIN if the file descriptor for the terminal is in non-blocking mode. (It isn’t by default, so most things will block.)
IIRC, scroll lock has an effect even while the kernel is booting, before init runs.
Anyway, the interesting thing to conclude from all of this is that Linux does not just send a ^s or ^q when you press scroll lock. scroll lock is directly linked to reads/writes from the console blocking.
This behaviour may or may not change a lot or a little in kernel 2.6, since the tty layer has been rewritten, or something like that.