The console-terminal-emulator(1) manual describes a mechanism where the automatic line wrap at the right margin is held pending until the next printing character is processed, in order to allow full-screen TUI programs to write right up to the lower-right-hand corner. This mechanism is formally documented almost nowhere else, but is implemented in almost all terminal types. The few exceptions are the “dumb”, “cygwin”, and “interix” terminal type families.

Writing in the lower-right-hand corner is not the only situation where applications must be aware of the effect of pending right margin wrap. In the pending state, the terminal cursor is in a different position to where an application would have expected it to wrap to, and relative cursor motions, including BackSpace and Next Line, need to account for this.

The “dumb” and “interix” terminal type families, and erroneously labelled “xterm” family terminals that are not genuine XTerm, do not implement the ECMA-48 standard Next Line control character. Applications must fall back to Carriage Return followed by Line Feed.

The “dumb” and “interix” terminal type families do not implement the ECMA-48 standard Reverse Index control character.

The “dumb” and “interix” terminal type families do not implement the ECMA-48 standard Index control character.

Only genuine XTerm and console-terminal-emulator(1) are capable of the Cursor Tabulation Control control sequence. For others, applications have to fall back on a combination of the TBC control sequence and the HTS control charcter.

Only genuine XTerm and console-terminal-emulator(1) are capable of the Horizontal Position Absolute control sequence. For others, applications have to fall back on the CHA control sequence.

Only genuine XTerm, PuTTY, Microsoft Terminal, and console-terminal-emulator(1) are capable of the Repeat control sequence. For others, applications have to fall back on explicitly repeating the characters.

The “dumb”, “konsole”, “linux”, and “teken” terminal type families do not implement the ECMA-48 standard invisible attribute, with the exception to the latter twain that console-terminal-emulator(1) implements it. “konsole” actively complains about its use.

The “dumb” and “konsole” terminal type families do not implement the ECMA-48 standard strikethrough attribute, and the latter actively complains about its use.

The “dumb” and “interix” terminal type families do not implement the ECMA-48 standard reverse video off SGR control sequence.

The “rxvt” terminal type family does not implement reverse video correctly. If the foreground and background colours are the same, instead of swapping foreground and background (as a real DEC VT does) it switches to the default colour.

There is wide disagreement on what the ED and EL control sequences do, when the DECECM private mode is off; with respect to the DECSCNM private mode. §2.9.7 of the VT520/VT525 Video Terminal Programmer Information [EK-VT520-RM] states that when the DECECM private mode is off “the background color used when text is erased or new text is scrolled on to the screen” is “the current text background color”. Everyone, that supports the DECECM private mode in the first place, agrees with this and always erases to the current background and foreground colours. The DEC documentation is silent on the point, but everyone also agrees that the reverse video attribute, and all other text attributes, are always off, thereby choosing (per ECMA-48:1991 §6.1.1) that an erased character glyph be indistinguishable from SPC.

However:

Although Microsoft Terminal supports the REP control sequence, it has a bug if it is applied to Unicode characters in Supplementary Planes.

The “linux” terminal type family, because of a long-standing bug, swaps the DECFNK codes for the Home and End keys on the editing keypad with those for the Find and Select keys.

The “interix” terminal type family reports function keys as Start of Selected Area followed by a character. To decode function keys from an Interix terminal emulator an ECMA decoder has to (mis)treat the SSA character as another single-character shift, like SS2 and SS3. It is effectively "Single Shift level A".

The “pcvt”, “cons”, and “teken” terminal type families generate the function key sequences that were generated by the SCO Unix Multiscreen virtual terminal. (In the case of the “teken” family, this is part of an admixture of DECFNK and SCO control sequences.) These SCO function key control sequences overlap with the DECFNK sequences for the cursor keypad and with the function key sequences generated by the “rxvt” terminal type family. Applications must only decode them as function keys when a terminal type that generates these sequences is in effect.

The “rxvt” terminal type family generates erroneous ECMA control sequences for function keys, where “$” is a final character instead of an intermediate character as the standard says. Applications must tweak their ECMA control sequence decoders to (mis)handle this character.

The “interix” terminal type family does not correctly handle CSI sequences containing private characters, emitting parts of them as printable output. In particular, this means that it does not implement any DEC Private modes at all.

Only genuine XTerm and console-terminal-emulator(1) understand DECELR and DECSLE. (Other terminal types actually process the control sequences incorrectly.)

Only genuine XTerm and console-terminal-emulator(1) understand DECSTR.

Only console-terminal-emulator(1) understands DECST8C. (So too does a Windows NT utility named ansicon, outwith the worlds of Linux and the BSDs.)

Only genuine XTerm and console-terminal-emulator(1) are capable of the DEC Set Number of Lines control sequence. For others, applications have to fall back on the DECSLPP control sequence and deal with the fact that DECSLPP 0 to DECSLPP 24 may be DTTerm extensions rather than number of lines.

ROXTerm and the VTE library actively wrongly decode the DEC Set Columns Per Page control sequence, treating parts of it as printable output. For those, applications have to fall back on the DECSLPP 8 control sequence if they can.

ROXTerm and the VTE library actively wrongly decode the DEC Set Left and Right Margins control sequence, treating parts of it as printable output.

PuTTY is known to not support DECNKM, and one has to fall back to DECKPAM and DECKPNM.

Only console-terminal-emulator(1) understands DECECM. For other terminal types, the erase colour mode is fixed.

For terminal types where has_DECECM is true, this is just the initial DECECM state. For other terminal types, it is the single fixed DECECM state.

The “dtterm”, “xterm”, “teraterm”, and “rxvt” terminal type families, Konsole, and VTE library terminal emulators are all capable of extensions pioneered by DTTerm that repurpose DECSLPP 0 to DECSLPP 24. DECSLPP 8 in particular sets both height and width in one control sequence. For those terminal types, DECSLPP 8 or DECSNLS (if supported) are the only ways to set heights less than 25. For other terminal types, DECSLPP can set all heights and widths have to be set with DECSCPP (if supported).

The “dumb” terminal type family, the “rxvt” terminal type family, and erroneously labelled “xterm” family terminals that are not XTerm, not the VTE library, and not Konsole, are not capable of generating XTerm-style ECMA-48-conformant mouse reports. (Other forms of XTerm-style mouse report are not ECMA control sequences, are problematic to decode, and have been deprecated in favour of the ECMA-48-conformant form since the 2000s.)

Only console-terminal-emulator(1) has a mode where all characters are full-width (i.e. "square"). Others display some characters half-width, and applications have to account for different character widths. This is also set true where the value of the TERM environment variable contains the “-square” feature suffix.

The “linux”, “teken”, and “rxvt” terminal type families, and console-terminal-emulator(1), effectively perform the action of DECST8C at terminal hard/soft reset, making explicitly setting regular tabs at 8 column intervals superfluous. (Real DEC VTs do not do this, and the initial state is for all tabstops to be cleared.)

The “putty” and “gnome”/“vte” terminal type families, and console-terminal-emulator(1) recognize sub-parameters to SGR 4, specifying various types of underline.

There are four different mechanisms for specifying colour: the original 8 SGR foreground and background colour sequences standardized by ECMA-48, an additional 8 SGR sequences (originally from AIXTerm) for a total of 16 (de facto and de jure) standard colours, ISO 8613-6/ITU T.416 Indexed colour (which conventionally has the 16 standard colours as the first 16 entries in the colour palette), and ISO 8613-6/ITU T.416 Direct RGB colour. Compounding this is that there are, because of a historical misreporting of ISO 8613-6/ITU T.416, two forms for the two ISO 8613-6/ITU T.416 mechanisms.

Emulating DEC VTs being the de facto standard of modern (character mode) terminal emulators, the de facto standard way to alter the cursor shape has been the DECSCUSR control sequence since the time of the DEC VT510/VT520/VT525. Being independently developed at around the same time, the Linux kernel's built-in terminal emulator has a quite different and idiosyncratic control sequence (LINUXSCUSR). XTerm extended the DECSCUSR control sequence with more possible cursor shapes.

Unfortunately, DECSCUSR is one of the control sequences that several terminals not only do not support but actively decode wrongly, treating parts of it as printable output. So applications cannot just emit it and leave it to be ignored where not implemented.