Off-by-one in RGB truecolor escape sequence parameter indices

VTE's main developer Christian discovered that pretty much everyone (including iTerm2, and us VTE too) misread/misimplemented the ITU Recommendation T.416 at truecolor escape sequences.

Seen from the comments in iTerm2's source, it expects RGB escape sequences as

CSI 38:2:rrr:ggg:bbb[:unused:tolerance:color_space_for_tolerance] m

and also accepts

CSI 38;2;rrr;ggg;bbb m

(without further optional parameters) for xterm compatibility.

Carefully reading the spec (which only allows ':' as the separator) the actual format is:

CSI 38:2:[color_space_id]:rrr:ggg:bbb[:unused:tolerance:color_space_for_tolerance] m

That is, there's an extra parameter at the beginning before the three color components. For example, to get red=255, green=128, blue=64, the sequence would be

CSI 38:2::255:128:64 m

Most apps that use truecolor emit the xterm-compatible escape sequences, because not too many terminal emulators support ':' as the delimiter, and understandably they choose the easy path which works everywhere. So I wouldn't touch the parameters of the semicolon-based sequence.

With the colon as separator, it would be nice to fix it and adhere to the standard. I'm a bit uncertain if keeping some level of backwards compatibility here (namely: if only three parameters follow the "38:2:" prefix then treat them as R, G, B) is a good idea or not.

Please see the VTE discussion for further details/thoughts.

I'm curious to hear your take on the story, and ideally key players of the story (i.e. popular terminal emulators) would agree on a direction to go.