The sad thing about tramp is that it requires code to be written agains it. When it was added to emacs, developers had not previously had to think that some buffers might be on remote machines and so their code would not magically work agains it. New code ought to be written with tramp in mind using functions that work remotely but this isn’t always done.
With a complex development environment (say compiler, separate autocompletion/jump to definition program, version control, maybe a test runner or other external programs) made out of emacs modes, it only needs one thing to not be made with tramp in mind or with bugs for the whole thing to fall apart in practice.
What I have is ssh access to a powerful development box and a relatively non-powerful desktop (possibly using multiple of these in one day). Everything runs on the dev box and I use emacs over ssh with x forwarding. This works fine (the network latency is low and I’m not super sensitive to it anyway) with some hacks to ssh back to the desktop to play sounds or open links, and a lot better than tramp or sshfs). But I am a bit worried about the future: emacs is becoming more graphically complex in various ways leading to more data needing to be transferred as the X protocol is less suited to it; and X (and in particular X forwarding) is dying for various reasons. Screen sizes are also getting bigger. A trivial update at 1080p takes a few hundred kB, a trivial update at 4K takes close to 1Mb, viewing an image takes a lot more.
The emacs future I’m hoping for isn’t so much a better tramp than a fatter emacsclient. That is, instead of using ssh to run emacsclient on a remote box, which causes the server to connect back through ssh to my X server to open a frame, I would run emacsclient locally which would talk (over ssh I guess) to the remote emacs and speak a more efficient protocol to it, and use modern apis to push the pixels onto the screen.
Emacs works great in a terminal, all the issues you mentioned disappear ;) (you didn't mention why you really need GUI Emacs) - I use emacs 95% of the time inside remote tmux sessions, you also have true color support is that your thing, what issues do you have?
Emacs in a terminal misses out on various text properties, on things like client frames (or just multiple frames in general), on images, and on font/size variety. I suppose you may feel like you don’t want to ever touch the mouse for some reason but I think it’s often useful for scrolling, selecting, copying, and pasting. There are also a bunch of keys which can’t be differentiated by a terminal. Finally the gui wastes less space on buffer dividers and the fringe
With a complex development environment (say compiler, separate autocompletion/jump to definition program, version control, maybe a test runner or other external programs) made out of emacs modes, it only needs one thing to not be made with tramp in mind or with bugs for the whole thing to fall apart in practice.
What I have is ssh access to a powerful development box and a relatively non-powerful desktop (possibly using multiple of these in one day). Everything runs on the dev box and I use emacs over ssh with x forwarding. This works fine (the network latency is low and I’m not super sensitive to it anyway) with some hacks to ssh back to the desktop to play sounds or open links, and a lot better than tramp or sshfs). But I am a bit worried about the future: emacs is becoming more graphically complex in various ways leading to more data needing to be transferred as the X protocol is less suited to it; and X (and in particular X forwarding) is dying for various reasons. Screen sizes are also getting bigger. A trivial update at 1080p takes a few hundred kB, a trivial update at 4K takes close to 1Mb, viewing an image takes a lot more.
The emacs future I’m hoping for isn’t so much a better tramp than a fatter emacsclient. That is, instead of using ssh to run emacsclient on a remote box, which causes the server to connect back through ssh to my X server to open a frame, I would run emacsclient locally which would talk (over ssh I guess) to the remote emacs and speak a more efficient protocol to it, and use modern apis to push the pixels onto the screen.