not really, they yield to other event sources, which is the opposite of waiting (which blocks forward progress and is a violation of real-time guarantees)

I think these things can be equivalent. It all depends on the definition of wait.

The simple example can be x86 with monitor/mwait instructions. These will suspend a hardware thread until it can be awoken when the memory write happens to the monitored address. Nothing happens on that cpu thread in the meanwhile. Yet at the same time if things are being virtualized the higher authority exists and it can do something else with the CPU until the write. Same for OS type of event synchronization like Linux futex.

I would argue that the wait abstraction is more powerful. The alternative isn’t powerful enough to enable these kinds of “wake me when I can be useful again” behaviors.

The actor itself can be said to be waiting. When it yields, the thread is then able to run another actor which was waiting on a message, and which then has a message on the queue.

That sounds like a misunderstanding of how the actor model works. An actor doesn't wait. It's an event-driven system, it doesn't get to own and decide when messages get fed to it.

Are there any actor system implementations that you know of that work differently?

Well in mine for example, threads are pinned to a core and always spin, and actors are pinned to a given thread (you can have an arbitrary number of actors per thread, they're just objects), so "waiting" is certainly not something you'd use to describe the setup in any capacity.

What happens when there are no messages on the queue for a given actor?

An actor does not have a queue; that's again the whole point I already made: it's event-driven, things are decoupled and the actor is not aware of how control flow happens.

Regardless, when the queue which exists and is per-thread is empty, the program terminates.