what about colours?

FTE's console printing is a bit different. Con_Print expands the string into colours+unicode chars first of all (using a generic reusable function to do so), then generates a list of buffers separated by the \ns. If it gets a \r then it arranges for the next char received to clear the entire line. Dynamically allocated, the screen width is not a concern. The console buffer is just a linked list of \n separated tokens, each char has its own flags for colouring.
The lines are wrapped at render time, where annother generic function splits the line into sub-lines that fit the width of the console.
Yay for centerprints reusing these generic functions too.

Advantages:
Console resizing just works. No weird single characters when resizing the window, etc.
Font code handles char width. No console resizing on font changes.
Doesn't waste memory simply because the user is running widescreen.
Can change the number of lines stored in the buffer with a cvar, without needing to memcpy everything or restart the client.
Colours are directly stored.
Disadvantages:
Moving up/down by one line has a tendancy to move up/down according to its \n chars rather than screen estate.
Doubly linked lists... And tracking pointers...
Can be a little slower...
Quake2 does Con_Printf("Loading %s...\r", model->name); etc in quite a few places. Its a nice trick. the \r does nothing until the next char is printed, which overwrites the first char of the line, so print the line, refresh the screen, load the model, print the next model and you don't spam the console needlessly.
Interestingly the same works for Quake. Beware of mods that spam lines with \r in them for some sort of radar!
\r is also commonly used in team messages in quakeworld.
It can also be used to put words into other people's mouths... say "\rIdiot: I'm a <INSERT INSULT HERE>"
You probably want to block that.
Fun stuff really.

.