I think the bounce looks okay, perhaps the screenshot was taken at an awkward moment.
If your results are working, then that's good. I'd be concerned about introduced bugs by changing the decimal conversion routine as you did, because there are perhaps 4 callers in the bank, but I could only discern what two of them were (party HP window and damage), and that greater-than-9 first digit -- and maybe semantically different other digits -- could in theory cause problems with the other callers. The fact that the original decimal conversion routine already did 5 digits makes me want to use it unmodified, but what you did could certainly be an ingenuitive hack to only write 4 (albeit special) digits, so long as no other caller got tripped up by it.
I fixed the "06" problem by making a few more 1-byte tweaks, but at least the "Miss!0" remains to be fixed. For my hack attempt, I am actually using all 5 digits (oddly yours is not...), so I think I actually need an FF written into the 5th byte to blank out any remnant digit. Like you, I wanted to avoid jumping to an unused section for additional assembly due to the conflict with other patches, but I was not able so far to fit a code change in place that sets the Miss sprites to also put a proper FF in there.
I forgot to touch on the ROL vs ASL topic before. ROL indeed works similarly to ASL, but where as ASL always puts a 0 for the new bottom bit and the top bit is discarded, ROL moves the carry flag into the bottom bit and then puts the top bit into the carry flag. That way the carry flag can be used as temporary memory, and that is why it is often combined into a 2-byte operation. i.e. during the first use, the top bit moves into the carry flag, and during the second use, the carry flag moves into the bottom bit. You can see how this mimics a single 16-bit operation. You'll also see that all uses of ROL or ROR probably have a SEC or CLC beforehand to ensure they know what the value of the carry flag is upon the first use.
