This is something we may be able to look at when updating Errai to CDI 1.1. Right now, we cannot manipulate Weld's context information without touching non-public (unstable, unsupported) APIs. This is the reason we don't support use of the AsyncDispatcher in conjunction with server-side Errai CDI: everything has to be done on the thread that originated the request, so Weld's context information is correct.
My understanding is that this context shuffling was made more explicit in CDI 1.1, but I have not yet dug into the new spec to see if the new APIs would allow the behaviour you're asking about.
As you say, acheiving the same functionality with the MessageBuilder from ErraiBus is simple. Just create a unique subject name for each private conversation, and the bus's routing logic will take care of sending the correct messages to the correct clients. No need to dig into QueueID and SessionID stuff at all!
The fundamental difference between the two approaches is that CDI is designed to be declarative and statically typed (even qualifiers must be known at compile time), whereas the bus is a programmatic API that allows you to create and destroy arbitrary subject names at runtime. In a use case such as yours, where not all users can be known at compile time, I think the dynamic/programmatic approach is the better fit–even if you can manage to figure out how to route the CDI events to specific clients.
Hope that helps,
Thanks, that answers my question.