How is /dev/console managed?

Before the GUI comes up, output to /dev/console
presumably is visible as text. Afterward, _something_
apparently captures the output. Perhaps the Console
app can show it too, although I must be missing it
somehow.

What I'd like to be able to do is intercept output to
/dev/console; not preventing it from going wherever
it goes now, but doing something with it, or at any
rate some of it; namely, filtering it a bit (maybe) and
popping up Growl notifications.

What brought this on is having a mixed environment
with both Solaris and Mac systems (well, one Mac)
at home. For example, Solaris NFS servers will
send a message using "rwall", which communicates
via rpc to rpc.rwalld (which in turn uses wall(1) to
write to all terminals). I ported rpc.rwalld from one
of the BSDs to Mac OS X with the only difficulty due to
the Mac's RPC APIs being different (and arguably lame).
But a Growl message for that sort of thing would be
the most friendly I thought about modifying rpc.rwalld,
but then thought it better to move it down deeper.
So I grabbed the Darwin source for wall(1), and thought
about putting the Growl notifications in there. But then
I thought, would it be _possible_ to solve this not only
for "wall" messages, but for anything else that gets
written to /dev/console too?

I saw the TIOCCONS ioctl in tty(4), but that seems to
suggest it only redirects kernel-originated messages,
and running xterm -C as root, and within it,
echo testing >/dev/console
does _not_ show the text written to /dev/console.

So I'm pretty much stumped as to how that's done.

Any hints? ("dump all those non-Mac systems" is _not_
acceptable :-)