So you agree that font rendering had to be extended to support color modifiers as specified in Unicode? That is the kind of completely creep that I am pointing out.

A bunch of control codes are historically part of character encodings, and their encoding is very consistent within codepages of the same family (ASCII/ANSI and EBCDIC). You don't have to have any awareness about the active codepage/language to handle them correctly.

Terminal escape sequences are a poor form of in-band signaling between devices (now virtualized), not text. I comsider that out of scope.

Anyway, as we get into the weeds here, I do not want to dispute the enormous practical utility of Unicode and I am glad that it exists and covers so many of the world's writing systems and alphabets. It is one of the central standards that connects people today. But from the purely technical perspective, the steady complexity creep is undeniable and brings somewhat hidden costs to software systems.

Font rendering has always had to adapt to colors. There were (non-standard) multi-color fonts in the 8-bit era, too. It's not just emoji that are using OpenType color tables and OpenType color tables are not the only way that colors in emoji have been handled, just one of the most standardized/algorithmic methods. Part of why they were standardized is how much they resemble other tables needed for complex ligatures in other languages that aren't emoji. Emoji didn't invent complex ligatures with multi-table lookup to render. Emoji benefit from simple extensions of the exact same mechanic. It's a new table, yes, but it is not a complex table, it's one of the simplest tables in OpenType.