I have not done a deep investigation of this issue but have a suggestion:You say in the original post that you "store" the original username in SPS session via IDMappingExtUtils.setSPSSessionData(key,value). This is definitely not how I would attempt to pass state information from one mechanism to another in a branching AAC policy. This was used in the *original* article because there was no policy context available when you "abandon" the choice policy and proceed on to the 2FA policy. Instead use something like:
context.set(Scope.SESSION, "urn:myns", "username", your_username);
Then in the SMS and TOTP policies (depending on their selection) you use this attribute (attributeName: "username", attributeUri: "urn:myns") as the way to feed in the username as input.