> Rich media elements: images, videos, tabulated results, etc. The terminal has needed an answer to these since 1985
No digital audio or video in 1985 (that'd be a challenge even high-power workstations were far from capable of doing) but lots of physical terminals supported graphics, in the form of Tektronix 401x (more common, implemented in xterm), ReGIS (available on DEC models with graphics), and Sixel graphics (based on printer graphics control codes, available on almost all terminals that supported Tek graphics, Tektronix ones excepted).
For all those, we'd need to arrive at a consensus of how many addressable points should a character cell have, because terminals are cell-based and GUIs are pixel-oriented.
> Fonts. Monospace is the best family of fonts for programming, but is objectively terrible for reading
Physical terminals could be augmented by optional (and sometimes redefinable) character sets that served to render multiple fonts and/or styles on screen (and some character-based graphics, and multi-cell alphabets for larger type). I'm not aware of any terminal from then that supported proportional spacing and implementing a TUI based on that would be painful, because the number of character cells in a row becomes dependent on what is in those cells.
> UI elements that aren’t built around ASCII bar characters for example
You can accomplish that with sixel graphics, but, again, terminal software writers would need to arrive at that same consensus about how many "sixels" should a character cell have in 2 dimensions. Some people want to throw historical accuracy (and existing software, such as GNUPlot) out the window, while others would prefer graphics to be consistent across character cell sized (so that a developer could rely on a box 60 sixels wide to have that many characters).
Furthermore, the problem with Slack and lots of other applications is not one of UI libraries, but poor resource management. Memory pressures for seldom-used entities, gratuitous animation, running more threads and concurrent requests than the CPU and the OS can handle smoothly, and so on.
> Rich media elements: images, videos, tabulated results, etc. The terminal has needed an answer to these since 1985
No digital audio or video in 1985 (that'd be a challenge even high-power workstations were far from capable of doing) but lots of physical terminals supported graphics, in the form of Tektronix 401x (more common, implemented in xterm), ReGIS (available on DEC models with graphics), and Sixel graphics (based on printer graphics control codes, available on almost all terminals that supported Tek graphics, Tektronix ones excepted).
For all those, we'd need to arrive at a consensus of how many addressable points should a character cell have, because terminals are cell-based and GUIs are pixel-oriented.
> Fonts. Monospace is the best family of fonts for programming, but is objectively terrible for reading
Physical terminals could be augmented by optional (and sometimes redefinable) character sets that served to render multiple fonts and/or styles on screen (and some character-based graphics, and multi-cell alphabets for larger type). I'm not aware of any terminal from then that supported proportional spacing and implementing a TUI based on that would be painful, because the number of character cells in a row becomes dependent on what is in those cells.
> UI elements that aren’t built around ASCII bar characters for example
You can accomplish that with sixel graphics, but, again, terminal software writers would need to arrive at that same consensus about how many "sixels" should a character cell have in 2 dimensions. Some people want to throw historical accuracy (and existing software, such as GNUPlot) out the window, while others would prefer graphics to be consistent across character cell sized (so that a developer could rely on a box 60 sixels wide to have that many characters).
Furthermore, the problem with Slack and lots of other applications is not one of UI libraries, but poor resource management. Memory pressures for seldom-used entities, gratuitous animation, running more threads and concurrent requests than the CPU and the OS can handle smoothly, and so on.