I am no clustering expert but I just went ahead and did some testing on Wildfly. In my scenario I used 4 nodes in a cluster and a load balancer in front of them (using httpd and mod_cluster).
I prepared a very basic application with one CDI session scoped bean and an index page which contained the information about which cluster node is serving current request, what is the application version and what is the bean content (I put a randomly generated number there and a message). This was a version 1.0 of the app.
Version 1.1 had another session bean added and obviously I changed the original bean message and app version.
In both cases the WAR I deployed has the same name (for instance testapp.war).

The rolling update was done in this way (hope it's clear enough, can hopefully provide further details):

• All 4 nodes went up with the version 1.0, here everything works as expected, sessions are preserved if you bring nodes down etc.
• Take 2 nodes down (preferably those serving your request) and update war files
  • Simply shut down servers
  • Remove original war file and replace with the new one
  • Meanwhile refresh the page from time to time to see the session is still in place and you are running version 1.0
• Bring back the updated nodes
  • Start them as before and give the balancer time to acknowledge this
• Take down the other two nodes and replace wars
• At this point when you refresh the page, the newly updates servers serve the request
  • Optionally you can bring back the latter two nodes to have 4 up with new app version
• Here comes the tricky part:
  • If you used ConfigurationKey.BEAN_IDENTIFIER_INDEX_OPTIMIZATION=true (this is by default) your app will crash here with IllegalStateException in server log
    • This is expected as the bean index depends on the amount of beans created which was changed by adding another bean
    • The web page will likely show an internal server error, at least for me it did
    • If you do not add/remove bean in new app version, it will likely work (though you typically need to add beans I guess)
  • If you used ConfigurationKey.BEAN_IDENTIFIER_INDEX_OPTIMIZATION=false (via property file for instance) your app will work like a charm
    • Here the bean index creation differs and is independent of number of beans
    • If you haven't lost your session due to timeout you will see the new app version and the old bean content since the session still holds
    • After session loss (timeout) you get a brand new session with all the new features as you would expect

The above observation was more or less expected behavior. It might be the case that the changes made in the suggested PR are Glassfish/Payara specific. I cannot speak for other servers though.

Note: You can read more about the ConfigurationKey.BEAN_IDENTIFIER_INDEX_OPTIMIZATION in the doc. Not using this config option is said to have a performance impact on session replication but I cannot say how big if any at all.