Muito bom o artigo! Essa modelagem explícita do estado "unknown" ataca de frente um dos erros mais comuns em integrações: tratar chamada de rede como algo puramente binário (sucesso ou erro), esquecendo que o servidor pode ter processado o POST e apenas a resposta ter se perdido na volta.
O impulso padrão de muita gente quando uma API não tem Idempotency-Key nativo é colocar um retry cego no catch, o que é a receita clássica para duplicar posts ou requisições. Salvar a intenção antes do disparo e reconciliar por leitura (fazendo um GET para checar a existência antes de tentar de novo) é o padrão correto.
Eu estava justamente fuçando no frontend do TabNews esses dias para resolver aquele bug do botão de compartilhar que sumia da publicação após enviar um comentário. Consegui arrumar o estado no React sem precisar de refresh, mas confesso que no final fiquei com vergonha de abrir a PR lá no repositório oficial kkkk.
Ler o seu post dissecando como o cliente e a API devem conversar com essa máquina de estados deu uma aula de como tratar incerteza de rede com rigor. Parabéns pelo post!