These days, yes. And also if you look at the low-level hardware. But there are a fair number of late-70s and early-80s computers out there where, without hardware modifications, you do not have access to the scan matrix and are effectively stuck with codes (often mapping fairly directly to ASCII) produced by some hardware not controlled by the CPU that's doing the scanning. The Apple II series is probably the most widespread example of this, but I own plenty of other computers (the whole Fujitsu FM-7 series is just one example) with similar design.

What you're doing, which seems to pretty much require control over direct keyboard scanning, is fair enough; I suppose I was misdirected by the "serial console" terminology and kind of assumed that you were aiming for arbitrary devices on either side.

_________________
Curt J. Sampson - github.com/0cjs

The display firmware I'm using doesn't print all the characters that a DOS machine can(The capabilities of this thing are inspired by my early days of programming under DOS and QBasic). Of particular interest are the codes $80 to $FF. I've used some of those as command codes, for things like graphics, setting cursor position, etc. Commands are variable length, but eventually it'll start behaving right, even if the internal connection drops out somehow.
I have the "advantage" that I'm designing towards a portable device, so I see no particular need to be compatible with anything else. I have to adapt software I don't write, but I feel like that's not too much of a disadvantage, since I use \n for a newline anyway.

A misconception: we don't need to control the keyboard scan. We just need to translate whichever scancodes the keyboard produces into the format we actually want to use. Since we have to do that translation anyway, it costs nothing to map Tab to $1F instead of $09, etc.