The following issue has been observed on Weld 1.1.x and Weld 2.2.x.

When using the Atmosphere Push Library https://github.com/Atmosphere/atmosphere (and potentially other libs or programming techniques) an Apache Tomcat 7 and 8 nio worker thread might stop processing one request and start processing another request without firing the requestDestroyed callback.
It can be assumed that this is correct, because the Push request has not been destroyed, it is actually still ongoing but no longer handled by a http thread.

The problem is that the second request on the same http worker thread will get a requestInitialized event.
The WeldInitial/EhancedListener will invoke

getSessionContext().associate(request)

however, because the worker thread was active it had a context which was not disassociated. Therefore the ThreadLocal in HttpSessionContextImpl ist still existing. As a consequence the current implementation will not set the session context but silently use it.

By not associating the context/threadLocal for the current session there is a session context from the previous request still active. This is especially a problem when the first request belonged to a different HTTP session.

This effectively leaks all @SessionScoped instances from HTTP Session A into HTTP Session B!

Fixing the issue is not really trivial, because the lifecycle of Push Requests (long polling, comet, websocket and derivates) is not clearly defined.
The best assumption that can be made is that with async push, ThreadLocals should not be used, because the Thread can serve multiple request "at the same time" (that is without firing callbacks to notice that the thread switched request).