So how is the modern way to work around issues like network partitions, servers not responding, going off and on on network connections, duplicate answers,....?
Futures-oriented programming - helped by the "async" or "generators" support in quite a few modern languages. Wrap timeouts and retries around everything, and process the timeout errors accordingly.
RPC doesn't mean that a remote function call looks exactly like a local one. That was a mistake. Modern RPC systems return composable futures which make it trivial to do timeouts and retries, send off many requests at once and wait for all/some of them to return, and so on and so forth.
If you're doing something that shouldn't happen more than once, generate a transaction ID to identify it by.
I strongly advocate GraphQL for client-facing APIs, and gRPC (or Thrift) for internal (or pure) APIs.
REST was a breath of fresh air after SOAP, but unfortunately it is an incomplete solution and leaves too many unsolved problems in user-space. This has led to a proliferation of attempts to build standards on top of REST, such as JSON-API. When we're building systems, RPC is a more natural fit because the semantics are clearly defined.