Imho there is some misconseption here, how the sixel protocol works for the colors part. It is not about any bit-depth of an image, as it is paletted. But other than most standard paletted formats, it can redefine its colors on-the-fly, which basically makes it supporting an infinite amount colors (it is still limited to 101³ colors in RGB space).

Now the actually tricky parts: The spec states (DEC STD 070), that the palette should be of size 256 at least on decoder side, and an encoder should not create more than 256 colors, and any higher palette index gets mapped back (not specced out, but mostly done with modulo). Older devices (old DEC printers or VTs) were even more limited in palette regards, from monochrome like VT240 to 16 colors on a VT340 for screen output. Thats what xterm does with `-ti 340` and it is totally right about it - it emulates what a VT340 was capable to do. What mlterm started to do (and others followed) - well it did not care for strict VT340 emulation, and increased the palette to 256 colors. Furthermore it applied "printer-behavior" (note - sixel was developed as printer protocol) deviating from DECs VT behavior by immediately applying colors to pixels. While DEC's sixel capable VTs always were bound to the fixed palette. That terminal vs printer behavior distinction is important, as it opens sixel to actually use more colors than the palette has room for by redefining color slots on the fly.

Hope this helps to get some details straight.