The reason it kills your session from page A is because, on the client side, sessions are implemented using cookies. Both page A and page B are trying to use the same session cookie, with different session IDs, so whichever one writes to it more recently kills the other one.
If you view your cookies using your browser's F12 developer tools, you should see one like this:
Name Value Domain Path
ORA_WWV_APP_115305 ORA_WWV_FMN08hWNhlkjRDOIU_y yoursite.com /pls/apex (etc)
This is the session cookie for APP ID 115305, and the browser will send it along with every HTTP request to yoursite.com/pls/apex. Apex uses the Value to verify that you are allowed to have access to the session specified by the ID in your URL. If you modify either the cookie or the URL's session ID, your session is lost and Apex creates a new one for you.
So the Name + Domain + Path forms a sort of unique key here. You can only have one session for each unique Name + Domain + Path cookie.
I think the easiest solution here is to put your public page B in a separate Apex App. That way it'll have its own session cookie with a different Name.
(This is how the Oracle App Builder, which is also an Apex App, can have a separate session going at the same time without killing your app's session. Its cookies use a Name like ORA_WWV_USER_9872)
The alternatives are to use a different Domain or Path for page B, but that's trickier.
It looks like you've set up a custom Authentication Scheme, so I think your cookie would look like:
Name Value Domain Path
SESSIONCOOKIE ORA_WWV_FMN08hWNhlkjRDOIU_y yoursite.com / (etc)
But you're still using the same Authentication Scheme (and the same cookie) for both page A and page B, so they can't have separate sessions. This would be an instance where it might be nice if Oracle supported using a separate Authentication Scheme for each page, but they don't. This is what separate apps are for.
