Sou usuário pesado do Screen há muito tempo, mas uso uma versão que modifiquei em 2002. Principalmente porque queria poder ter a janela "próximo / anterior" da ordem de navegação correspondente à ordem em que novos janelas foram criadas, semelhante a um gerenciador de janelas lado a lado como i3 ou Ion . O comportamento padrão da tela é que 'next' e 'prev' passem pelo número da janela, de modo que geralmente uma janela 'nova' (pegando o menor número disponível) esteja localizada em outro lugar que não seja a próxima janela - confuso se você não ' Não lembro dos números. Desde então, meu comportamento preferido foi implementado no Tmux como um sinalizador para o comando new-window em 2010 e a opção renumber-windows em 2012. O patch My Screen, que tentei tornar o mais aceitável possível, incluindo adições de documentação e assim por diante, não gerou nenhuma discussão na lista Screen em julho de 2002 (então "screen@informatik.uni-erlangen.de" não pode encontrar arquivos). Na verdade, isso nem foi reconhecido, mesmo quando o enviei novamente um ano depois.
Desde 2002, "reformulei" meu patch algumas vezes para aplicar nas versões mais recentes do Screen. No entanto, quando cheguei à versão 4.3 (2015), notei uma alteração não documentada que interrompeu um dos meus usos de tela - ou seja, que 'coisas' agora interpolam variáveis de ambiente . Eu não precisava desse recurso e não conseguia descobrir como escapar facilmente do argumento para 'coisas' (para que eu pudesse enviar texto contendo cifrões), então continuei usando a versão 4.0 (de 2004).
Eu uso o 'material' do Screen ('send-keys' no Tmux) em uma função Emacs que envia o conteúdo da região atual do Emacs para um número de janela específico. Dessa forma, quando escrevo código em uma linguagem de script, abro um intérprete, dou um número especial à janela do intérprete e posso enviar linhas de código da minha janela do editor diretamente para a janela do intérprete usando essa ligação do Emacs. É hacky, mas eu gosto mais do que a solução pure-Emacs , já que também posso interagir com o intérprete na janela Screen usando as teclas padrão. É um pouco como um IDE da GUI, mas não preciso usar o mouse ou olhar para um cursor piscando.
Outro recurso que implementei no meu patch é a capacidade de "marcar" uma janela e, em seguida, reposicionar a janela marcada para ser "próxima" após a atual. Para mim, essa é uma maneira muito mais natural de reorganizar as janelas do que renumerar; é como o paradigma de copiar / colar ou "arrastar e soltar". ( Recentemente, eu também descobri como fazer isso no i3 .)
Deveria ser possível fazer o mesmo no Tmux, por exemplo, a partir de 2015, existe uma facilidade para "marcar" um painel. Ou talvez uma solução mais elementar possa ser elaborada com scripts de shell com estado. Eu implementei um script curto e combinações de teclas para tentar o método "painel marcado", e funcionou algumas vezes, mas o Tmux travou com "[servidor perdido]". Então eu encontrei o Tmux travando mesmo sem tentar fazer nada complicado. Aparentemente, ele está travando para alguns usuários há alguns anos, pelo menos . Às vezes, o servidor trava, outras começa a usar 100% da CPU e deixa de responder. Eu nunca vi a tela fazer um desses.
Em teoria, o Tmux é superior ao Screen de várias maneiras. Possui capacidade de script muito melhor, o que significa que você pode fazer coisas como consultar a lista de janelas na sessão atual na linha de comando, o que é impossível com o Screen. Por exemplo, em 2015, a Screen adicionou um comando para "classificar janelas por título" . Não tenho certeza de quando um comando tão especializado seria útil, mas esta e mais variações práticas (por exemplo, classificar janelas pelo uso da CPU) poderiam ser feitas com relativa facilidade a partir de um script de shell no Tmux. Para mim, parece difícil fazer algo tão criativo em Screen, pelo menos sem modificar o código C.
Como outros pôsteres mencionados, o Tmux tem um modelo de servidor único que eu vejo como a principal desvantagem, principalmente quando o servidor está travando. É possível contornar isso especificando um soquete separado para cada "sessão". Ainda assim, prefiro o padrão de um servidor por sessão da Screen, que parece um pouco mais elegante.
Trabalhar com o código Screen, em 2002, foi educativo e agradável para mim. Curiosamente, por todos os seus recursos adicionais, o Tmux tem cerca de 25% menos linhas de código que o Screen (30k vs 40k). Percebi que o Tmux usa muitas estruturas de árvore e de lista de dados, que eram um pouco difíceis de entender. Tela parecia preferir matrizes.
Pelo que entendi, como a interface do terminal Unix é muito estável, há pouca necessidade de o código Screen ou Tmux se adaptar às mudanças no sistema operacional subjacente. Esses programas realmente não possuem atualizações de segurança, como navegadores ou servidores da Web ou mesmo o shell. Não notei nenhum problema ao executar minha versão personalizada do Screen, atualizada pela última vez em 2004 (exceto pela necessidade de adicionar alguns arquivos de configuração para impedir que o Systemd exclua o soquete; esses arquivos geralmente fazem parte do pacote de distribuição). Talvez eu pudesse solucionar os problemas encontrados no Tmux executando uma versão do Tmux antes de começar a falhar. Obviamente, se um número suficiente de usuários fizer isso, não será muito bom para novos usuários, pois significa que menos especialistas procurarão bugs nas últimas versões oficiais desses programas. No entanto, é difícil me motivar a mudar para um produto que seja instável para mim (o mais recente Tmux) ou que não tenha certos recursos que eu quero (tela padrão).
Sei que isso não fornece uma resposta fácil para a pergunta do OP, mas espero que minha perspectiva tenha sido útil.