Well, it’s more complicated, but in theory you could do some deep packet inspection that understands the protocols: personally, I’d use this to break DoH connections (for every host name seen in SNI, attempt a DoH query, if it resolves, reset the connection) and attempt to force everything to fall back to plain DNS. Then, whitelist a couple outbound ports (on most networks, maybe just 443 + 53?) and block VPNs.
With the Portmaster (https://github.com/safing/portmaster) we're going in that direction, but it will take a couple more years to be able to go that deep. Have a look!
Also, with things like this, you can just reset connections using HTTPS features you don’t support. It might eventually become painful, but it’ll be fine for the near future. And, if enough enterprise middleboxes do this, the standards will be DOA.
Except you can already query/set the color palette to arbitrary RGB values with control sequences (at least with xterm, rxvt-unicode, and I imagine others).
As far as I've been able to tell, "truecolor" terminal support is about simultaneous display of a range of colors beyond what fits in a palette. Which, eh...seems a bit much for a terminal.
You're right, but I think that truecolor support is easier to program.
I vividly remember when I wrote DOS programs which used VGA/SVGA graphics in the early 90s; switching from palette-based colors to RGB colors was something I really enjoyed! Back in the 90s, loading a 256 color image that used its own palette into DeluxePaint would change the colors of DP's interface too.
Something similar would happen today under tmux, I think: if two side-by-side panels contain two different programs, and one of them reprograms the palette, the other program would be affected too.
Although there's some real gems in there (I can't believe I never ran across vipe before!), its Debian package conflicts with the GNU parallel package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718816 Quite annoying.