@draegtun made the objects and the hooks (docs)... I've done the general architecture, in particular pushing as much as possible into usermode code vs. C. Also to make errors that occur while running the input processing hooks cause it to fall back on the default console, rather than put you in a situation where you cannot debug your hooks.
Windows was originally done through one atomic ReadLine call that could not be interrupted. This is provided by the Windows API, but it is a very limited call. There is no customization possible...you'd hand control to Windows and it would not give back control until a line of input was obtained. So its history was whatever the windows console happened to give you.
There is no comparable API on POSIX. There is GNU's libReadline library which Rebol could have been linked to...but it is a bit bulky by Rebol standards and also GPL, so it was not used. So terminal interaction code was written in C that handled it in a "micromanaged" way. It was very poor, and R3-Alpha demonstrates how limited it was. But since no history was available as in the Windows console case, it made the reading of lines linked with its own mechanism.
What I did was to morph the POSIX version of the code bit by bit in a way that it could be common with Windows, and switched Windows to provide the more granular events to match. The history actually is a BLOCK! (of strings), it's just not exposed outside of the C.
(I'd like to see the history be more intelligent with respect to command groupings; I want to page through full commands, not lines...however that could be made to work.)
Desirable or not, it should be able to work in a micromanaged way...running the same code...if it wanted to. So it makes a good test.
What granularity you cut in at should be able to vary. If you want a multi-line edit box to gather the code, that should be a possible response...but if your terminal is dumb, it defaults to a dumb behavior.
I think being able to share an implementation is important enough that's a good start. If I want key granularity and draw the terminal interface one character at a time, I should be able to have key granularity and draw the terminal one character at a time.
That's the hard problem: making it so your configuration and keyboard shortcuts do magic equally on the desktop and on the web. Splicing in a hack here and there to take advantage of better mechanisms when available isn't nearly as difficult.