It's one single source, not multiple vendors.
Nearly all of what you mention actually comes from one source, DEC VTs. The various different control sequences generated by the function, cursor, editing, and calculator keypads that you mention pretty much all, with a couple of exceptions, have their roots in DEC VTs.
A DEC VT had a slightly different (native layout) keyboard to the IBM PC/AT keyboard descendent that you are likely looking at. Most notably it had the PF1 to PF4 keys on the calculator keypad, had the Find and Select keys on the editing keypad, had 20 function keys rather than 12, and lacked the concept of ⇭ Num Lock.
Rather, it had the concept of modes. The cursor keypad and the calculator keypad could be operated in two modes, application and normal modes. The keys on these keypads would send different control sequences to the host according to the current mode, which was controlled by a control sequence (a different one for each keypad) sent from the host to the terminal.
The DEC VT system is actually fairly logical, although this has to be teased out of the docs slightly. A terminal keyboard basically generates two sorts of control sequence: a variable length one beginning with the Control Sequence Introducer (CSI) character and a two-character sequence beginning with the Shift State 3 (SS3) character.
(You have to know, at this point, that these C1 control characters are the underlying control characters that are involved. The ␛ [, ␛ O, and ␛ N sequences, that you may have thought were the control codes, are in fact what ECMA-48 terms 7-bit code extensions. They are ways of encoding the C1 control characters for transmission paths that are not 8-bit clean. All C1 characters have a 7-bit encoding. Ironically, given how long these 7-bit encodings have lived on, terminal I/O has been 8-bit clean for decades now.)
There are a lot of CSI control sequences, varying according to what intermediate characters, parameters, and final characters they have. ECMA-48 documents them, their standard structure, and provides a way for vendors to have private-use control sequences. ECMA-48 even defines a specific control sequence for encoding function keys, FNK.
DEC VTs do not use FNK.
DECFNK and application mode
Instead, they use DECFNK. It's one of those private-use extensions, a CSI control sequence that has a final character, ~, that is in the range reserved by ECMA-48 for private-use control sequences. DECFNK control sequences have two parameters, the first denoting the key number of the main key and the second denoting the ancillary modifier keys (⇧ Shift, ⎈ Control, and ⎇ Alt) that were also pressed at the time.
The numbering of the first parameter seems crazy, with odd gaps, until one looks at a DEC VT keyboard. Then one realizes that the numbering simply follows the physical positions on the keyboard:
- The editing keypad comes first, proceeding from left to right, from Find as 1 to Next as 6.
- The cursor keypad comes next, with the cursor keys numbered from 7 to 10. DECFNK is only used in certain circumstances for these keys, but these are nonetheless their documented numberings.
- Then comes the function row, with 20 function keys numbered from 11 to 34. This includes the 18 function keys that are labelled as such, and the Help and Do keys that are on that row. The gaps in the numbering simply correspond to actual physical gaps in the function key row.
The calculator keypad is not covered by this because it has no need of such control sequences in normal mode. In that mode, all that it generates are ordinary numeric and punctuation characters, after all.
The cursor and calculator keypads on a real DEC VT can be switched to application modes. The original idea behind this is that mainframe/minicomputer applications connected to DEC terminals could switch the terminal into application mode and thereby give the user what amounted to a huge bunch of extra application-defined function keys.
This is where the two-character sequences come in. The SS3 control character is a single shift, a temporary change of "shift state" to apply to one immediately following character. It is this that is used to encode cursor and calculator keypad keys when in application mode. Again, the system is fairly logical, with the "shifted" character being a different lowercase letter of the alphabet for each key on the keypad, in roughly bottom-to-top order of the physical key positions.
Of course, the editing keypad on an IBM PC/AT descendant keyboard does not have Find, Select, and so forth. It has Insert, Delete, and so forth, in the same positions. Similarly, an IBM PC/AT descendant keyboard has a calculator keypad that has the concept of numeric lock that turns it into a bunch of cursor and editing keys. Then there is the fact that on a DEC VT, the F1 to F5 function keys were (usually) local only, and never generated input to the host. So most terminal emulators have coöpted the codes from the PF1 to PF4 keys on a DEC VT's calculator keypad for those function keys.
These all complicate things somewhat. I won't go into the complexities because they do not affect the core thesis of this answer. The keys still end up generating DEC VT terminal control sequences.
So to apply all these to some concrete examples from the question:
- DECFNK 1 (CSI
1 ~) is the control sequence generated by the Find key on the editing keypad.
- DECFNK 17 (CSI
1 7 ~) is the control sequence generated by the F6 function key.
- DECFNK 15 (CSI
1 5 ~) would be the control sequence generated by the F5 function key, were it not for the fact that on most of the DEC VT range it cannot be taken out of local mode at all.
- Note that DEC VTs have a gap between F5 and F6. Hence there is no key that generates DECFNK 16. That minicom sends that for F5 is an outright error. But it's an error probably inspired by the fact that the gap is between F4 and F5 on a PC/AT keyboard, and exacerbated by the fact that one has to look quite carefully in the DEC docs to find the code for F5.
- DECFNK 11 (CSI
1 1 ~) is the control sequence generated by the real F1 function key on a DEC VT, which could be changed out of local mode.
- SS3
P is the control sequence generated by the PF1 calculator keypad key on a DEC VT, used by terminal emulators (running on PCs) for F1.
- ⌫ Backspace generating either
␈ or DEL is actually a switchable thing on a real DEC VT. There's a DECBKM private-use control sequence that a host can send to control it.
- CSI
A, CSI B, CSI C, and CSI D are Up, Down, Right, and Left when the cursor keypad is in normal mode. These are almost, but not quite, the same as the output control sequences sent by the host that cause cursor motions. (The difference is beyond the scope of this answer, though.)
- SS3
A, SS3 B, SS3 C, and SS3 D are Up, Down, Right, and Left when the cursor keypad is in application mode.
… and the rest is SCO.
I did say that there were exceptions. These exceptions largely exist in the terminal emulators built into operating system kernels like Linux and the FreeBSD/NetBSD/OpenBSD kernels. They also largely have a common ancestor, though: SCO Multiscreen and the SCO console.
Some of the control sequences that you'll see sometimes from combinations of modifiers and the 12 IBM PC/AT function keys in PC terminal emulators are still the ones from the SCO console. But there is more that just that. On the SCO console (and also in a DEC VT's "SCO Console Emulation" mode):
- CSI
H is ⇱ Home.
- CSI
F is ⇲ End.
There's even more to it than that. SCO Multiscreen used ⎇ Alt+Fn for switching between screens, for example. And UnixWare keyboard map files will look quite familiar to FreeBSD users.
Further reading
