I think the pain-point being designated by the OP is that the cure is worse than the disease:

    Problem = tight coupling
    Solution = x, where x => {indirection, implicit_coupling}

I'm not sure I agree the final judgement call, but the analysis is spot-on. Message-passing interfaces are generally difficult to discover and to debug, and require a lot of careful documentation, logging & instrumentation.

> Message-passing interfaces are generally difficult to discover and to debug, and require a lot of careful documentation, logging & instrumentation.

You just use the "most common structures". For example, Elixir has the Agent module, which encapsulates state, but lets whatever you're using interact with the state via lambdas (or passed functions).

Another common structure is the state machine. I was somewhat displeased with the complexity of gen_statem, so I wrote my own! It's about 50 lines of code, and can have plugins to do facilities like logging and debugging via a plugin-able interface.

Ultimately the real win with message-passing is not having to write spinlocks, semaphores, or mutexes.

So you create a function around the message. It's not uncommon at all to have something like (pseudocode)

myActorModule.increment(ref, amount) -> ref ! {increment, amount}

myActorModule.syncIncrement(ref, amount) -> ref ! {increment, amount, self()} receive -> ok timeout 1000.

You can build out the message passing interface to an actor -as- functions, and even supply sync ones if you want. The actor implementation can be completely opaque to the caller; just the exported interface functions are defined, exported, and supported.