I was just thinking this myself. I was thinking about a small, limited-vocabulary (widgets) GUI toolkit (implemented without web technologies) inside of Emacs that could still be navigated with a keyboard. GUI windows would be differentiated from buffer windows, and so functions that are defined for one of them couldn't be enabled on the other. Packages could implement their functionality in either type of window, or both, depending on their purpose.
> I enjoy using a TUI for certain things, either on low-resource devices, or an actual vintage terminal, and so on. [...] That's something I'd dearly hate to lose.
In the imaginary implementation I described above those would still work, they would be buffer-interface-only packages. They wouldn't have to be re-implemented nor updated to keep working properly.
> You could sort of work around that by defining abstract widgets and providing both GUI and TUI implementations, but that constrains the GUIs a lot [...]
It doesn't have to be that way. If GUIs and buffers are defined as different types of interface paradigms that can be used and modified within Emacs, then GUIs could be completely different from their buffer counterparts and vice versa. Packages that wouldn't make sense having on a terminal wouldn't have to implement a buffer interface for it. And not every package would have to implement its own GUI interface either if there's no need for it; buffers are a very simple data model with a vast amount of tooling for them that can all (in theory) work in tandem, so they would still be an attractive baseline for any developer looking to extend the functionality of their editor.