Correct way to repair a function flow for obfuscated code

[msm-code]

This is the obfuscated code I work with. After marking some fields as constants, Ghidra almost overcomes it:

(ignore the GS_OFFSET, it's a result of me doing random changes, it has no relevance to the decompilation

The issue is:

• decompiler understands where the jump goes, but since it technically goes outside of the function (as defined in listing), it marks it as an external call
• disassembler is too limited to understand where the jump goes, so it needs manual fixing

While in reality, this JMP is just pointless obfuscation that goes to the next function instruction.

Now, there are a plenty of manual ways to fix it:

• I can set fallthrough override of ADD R10, RBX to 1406304ad
• I can add a COMPUTED_JUMP reference to 1406304ad, and set flow override of JMP R10
• Equivalently, I can add a COMPUTED_JUMP reference to 1406304ad, and run SwitchOverride.java
• I can patch JMP R10 to JMP [constant] or NOP it in this particular case

With exception of SwitchOverride that does it automatically, I will also have to use the script console to execute CreateFunctionCmd.fixupFunctionBody, in order to let Ghidra know that this new fragment of code belongs to the original function (out of curiosity, is there a way to do this from the UI? "Clear flow and repair" doesn't help.).

Finally, there's no obvious non-hacky way to automate it:

• SymbolicPropagator is not powerful enough to recover R10 value at this place (may be related to this issue, but I suspect it will always be less powerful than the decompiler)
• As far as I can see, high pcode doesn't have this constant readily available:

...
(unique, 0xdc00, 8) LOAD (const, 0x1b1, 4) , (register, 0x90, 8)
(unique, 0x1000009d, 8) INT_ADD (unique, 0xdc00, 8) , (const, 0x6cfc731083e98da2, 8)
(register, 0x90, 8) CAST (unique, 0x1000009d, 8)
 ---  CALLIND (register, 0x90, 8)
 ---  RETURN (const, 0x1, 4)

• I can probably implement my own symbolic propagator based on high pcode (I sort of already did already once), but it feels wrong - Ghidra already knows the answer.
• Technically I can get this constant from DecompilationResult.getCCodeMarkup() - that's why I specified a non-hacky solution :)

Is there something I'm missing? What is the best way to proceed? I'm OK with scripting my way out of this, but I want to reuse ghidra features as much as possible.