My major concern is that there is a huge difference between the actual usefulness of unix signals, that is mostly limited to killing processes or signaling tiny bits of information (like when you send a signal to reload a configuration), and their semantical complexity.

I must admit it is not trivial to replace this system with another equivalent without changing a lot of how Unix works. For instance signals are used in order to interrupt a program: if you don't make this trappable (like kill -9) then programs can't recover or prepare in any way before quitting. An alternative can be to just allow a signal handler to fire that will never return.

From this point of view you could even just have two signals, with the only goal of stopping processes, one in an hard way (SIGKILL) and one in a soft way (SIGINT), firing a signal handler (but the process will terminate when the handler returns). This way you don't need handling the interruption of syscalls nor writing "safe" signal handlers. As you said signals are interrupts. If the interrupt handler can never return a lot of problems disappeared.

All the other tasks currently performed with signals should use a more general and saner message bus, with select(2)able file-alike interface.