I feel like there is a fundamental misunderstanding about how to think about systems within the Erlang/Elixir paradigm at play here, and it’s affecting the core design and thinking about how to structure your application(s) to resolve your problem.
A microservice is a program that is designed to have a small area of responsibility, and thus a small surface area when it comes to its API. It can be launched on the same or different hardware stacks as other microservices, but that is a deployment detail that can mostly be ignored.
A process, be it a GenServer or whatever, is a unit of concurrency within the Erlang/Elixir ecosystem. Schedulers allow processes to also be run in parallel, but even that is a result of the concurrent aspect of processes.
Trying to map these two concepts together, with a process equaling a microservice, is going to lead to problems as they are not the same. A microservice could easily be made up of thousands of running processes, or just one…well two if you count the application supervisor.
Similarly, attempting to do clever tricks with blocking rpc calls, or manually controlling the launch of Elixir applications on different connected nodes–while possible–is just increasing the possible configuration and debugging pain points of a running production system. I also just see it as a lot of added complexity that isn’t needed if you just design your solution differently.
If you aren’t going to make a true stand alone microservice (that communicates in a language agnostic protocol) and want to use the slick Elixir communications tools and interconnected nodes…why hang onto that concept at all and not just dive straight into solving the problem the Elixir/Erlang distributed way from the beginning?