Ok, so you're interactively using a program on a remote server and you don't want it to die if you lose your connection? Screen isn't a hack in that case :)

Although you could ditch it and use MOSH instead.

It presumably doesn't feel like a hack to you because you're used to this mindset.

To me, it's a deficiency in the lack of session management for SSH. All that SSH gives me is a two-way pipe to the other server's I/O. That's simple and elegant, but why does it create a new pipe every time? It's connection-oriented, which is a concept that hasn't seen any innovation since the 1970s.

My preferred innovation here would be a local shell that had remote access. Rather than pipe I/O to the remote shell, give me a local shell which happens to execute its verbs on the remote machine, and let the remote file system simply be a volume. All my session state (including command history) can be local, there's no need to keep that on the remote host. A remote host is just another context.

I believe Plan 9 tried something similar, but very few people have picked up on its innovations.

Maybe you want eshell then:

    ~ $ cd /ssh:tol-eressea:.
    /ssh:tol-eressea:/home/db48x $ ls
    db48x.net  libvirt-sandbox  rpmbuild  zone.sh  zone.sh~  zone.txt  zone.txt~

If you've set ssh up to use control sockets then it can reuse existing connections.

MOSH is also nice; it decouples the program you're running from your connection, just like screen does, and it also uses udp instead of tcp so that it doesn't have to worry about dropped connections. Even your client's ip address can change and everything keeps working.

or you could type CTRL+Z BG

Still can't reattach after logout/reconnect, which is a very common screen/tmux use case.

And that will still send the program SIGUP, killing it when you close the terminal or lose your ssh session.

You can do that (or spawn in the background from the start, with &) while also using nohup.