Edit current instruction generates wrong input text when an integer token's value is in the middle of a function

The title might be a bit confusing, but it is quite straightforward from the image. For the instruction at 0x40167f, the token is rendered as sub_4016f2+1 because there is a function at 0x4016f3.

Now if we press E to edit the current instruction, the candidate input text becomes this:

The input text can be assembled properly, but it is different from the original instruction. The operand will become 0x4016f4. The reason we get this is because we are dumping every token in a verbatim way, and for the sub_4016f2 token, its value is actually 0x4016f3.

Another interesting behavior is we can right click the token sub_4016f2 and set its integer display type to unsigned hex (rather than default), this will force the token to be rendered as 0x4016f3, which will avoid the above issue. Though this is not very discoverable since the user may think there are already two integer tokens, and setting the integer display types will only make things worse.

Database:
heaven.exe.bndb.zip

Original crackme: https://crackmes.one/crackme/64f1f77ad931496abf90951d

Reproduce the issue with the linked heaven.exe.bndb database at instruction 0x40167f, then trace the Edit current instruction flow and how integer tokens are rendered into candidate input text. Compare the displayed sub_4016f2+1 operand with the assembled result and verify that editing preserves the original instruction value.