I re-ran my test to see if this had been fixed in the released version of GlassFish 4.0, and I can confirm that I no longer see this error.
I tested with GlassFish Version: GlassFish Server Open Source Edition 4.0 (build 89)
My test case used a stateful session bean which had a business method which uses an injected JMSContext to send a message without a transaction. This means the injected JMSContext had request scope. I set <cache-idle-timeout-in-seconds> to 2 seconds.
I then called the same stateful session bean several times within the same request, with a pause of 20 seconds between each call (i.e. longer than the specified <cache-idle-timeout-in-seconds>) to encourage passivation to take place in between calls.
I used log statements to confirm that the bean was indeed passivated in between two such calls, and that after the bean was activated the injected JMSContext was proxied to the same underlying JMSContextImpl.
JMSContextImpl is not Serializable and this test confirms that it does not need to be. Even though a stateful session bean may be passivated in the middle of a request, this does not causes any problems if the bean uses an injected, request-scoped JMSContext. This is because although the field in question is serialized, this is just a proxy generated by Weld. The underlying JMSContextImpl is not serialized but continues to be managed by Weld. After the bean is activated, this proxy is deserialized just fine, and when it is next used Weld makes sure that it is fixed-up to point to the correct JMSContextImpl instance for the current request.
I think that this issue can be marked as resolved.