Welcome to the JavaRanch, Dom!
I could actually try and comprehend your question, but that's too much work too early in the morning.
So I'll make some general observations and see if they fit.
In
J2EE, there's a bit of a blur between a container-managed security session and HTTPsession. I think that starting in JEE, they've begun to make more of a distinction, but that's another matter.
In any event, in J2EE, the way to log out of a container-managed security session is to invoke session.invalidate(), as your examples do.
But sessions are more than just security. You MUST have (will be supplied with) an HttpSession when you're logged in with CMS, but you CAN have an HTTPSession without being logged in!
JSF tends to confuse the issue. If a JSF process logs out via session.invalidate(), the security session will be destroyed, as will any session data attributes such as session-scope bakcing beans. But JSF uses HTTPSession more frequently than other frameworks. For example, if you display a post-logout screen that references a session-scope backing bean, a NEW session will be created to contain it. This new session won't (yet) be secured - unless the post-logout screen is secured - and it won't have any of the previously-discarded session objects in it, but it will contain the new session objects.