AWD interacts with the applyDamage function that you also change, which breaks the 'assumption' in your extension that you can hold the decodedDamageText as static. Because it is not.
Since applyDamage is calling the decodeDamageText the inputs to applyDamage can be 'adjusted' in extension. Like you do in your extension. I just dont assume that it is 'static' or that no other extension could possibly be in the calling stack of overrides for applyDamage call chain.
The issue is that your extension 'assumed' that once you had processed 'applyDamage' and then called down into the 'chain' of possible other extensions that could overload this function, that they would not also change something in the call process. ( Which since you wrap this function to apply your own changes, you can not assume other will not also apply changes before it hits the actual ruleset function. ) Your extension is holding the value from your extension level call, and then passing it back into the 5e ruleset version and assumes nothing will ever happen to it or be between you and the ruleset function.
AWD also scans the damage lines before calling the ruleset applyDamage, and can change the lines. Which makes this a dynamic item. Your extension should not be assuming it is static which it will be if no other extension is in the stack that access/changes the applyDamage function.
I dont think the suggestion change I've posted will cause you any issue, because AWD does not change the decoded outputType which is what you are holding from the stored value. You could reduce what you store in the local value to just that one item. Then not have caused this conflict.
The reason I can not fix it in my extension, is because yours sits on top of mine and is pushing back in the stored values. Without changing my load priority I can not resolve it. As far as I know my extension does not break your extra codes as they pass through my extension. But in theory we could have some extra interaction like this. ( Like the 'transfer' damage code I already talked about. )
I also do not think you should be doing 'extra' work in the 'messageDamage', as people will not be expecting this. I know you do it so you do not have to adjust the applyDamage function in a mid code point, which causes a possible massive conflict point. So I understand why you do this. But I suggest you look to see if you can do this work before the applyDamage or post the applyDamage function. But this would be a more of the re-write I think you should do.
I do think you should just store the 'decodeResult.sType' which is all you use outside the applyDamage function, then you could store this at the point you 'decodeDamageText' in your applyDamage function, and then totally remove your access to the 'decodeDamageText'. Since you link into messageDamage you can use this to change your sTypeOutput to "maximum hit points'. I've not looked into the 'effectmanage/actiondamage' calls in applyDamage so it might not be possible to remove the decodeDamageText 'sTypeOutput' change.