A FIFO is a valid strategy to implement actors model, in the sense that it doesn’t violate any actors model semantics. But there are serious problems with using this strategy: developers will test their programs with it and never see errors that the semantics allow, may even learn the strategy and intentionally write code depending on it.
The result is application code ‘coupled’ to the language implementation rather than to the semantics. Not only is such code unportable (to other implementations of the same language), but this ties the hands of the language developer who might later wish to improve support for inlining optimizations, parallelism, or distribution
Language developers should protect their semantics. In the actors model case, I would suggest emulating the freedom of the actors model via partially randomized ordering for messages, or even heuristics and strategies specifically aimed at breaking the app – at least in debug mode.
But language developers can also work from the other direction: they can protect the ‘implementation’ semantics by making them explicit. For example, developers could define actors together within a message-passing membrane (e.g. E’s vat semantics), and the membrane would allow developers to choose a message-ordering strategy. This option has significant side-benefits of allowing developers to more effectively reason about code and guide implementation properties (such as parallelism and distribution).
For RDP, temporal semantics and explicit delay render arrival order a non-issue. But I do have my own beast to tame: disruption. While RDP is designed for disruption tolerance, that doesn’t mean I want to worry about disruption between arbitrary agents. My current plan is to offer some control over grouping of agents and failure escalation (so we disrupt whole cliques rather than between arbitrary agents). I’ll discuss this more thoroughly in a dedicated post.