Our QA lead filed a bug that we nearly closed as "works as designed."
Someone entering an amount on a payment form typed 12.50 and submitted 1250. The field was reformatting on every keystroke. As soon as a group separator appeared, the caret jumped to the end of the text, and the next digit landed where the person never aimed it. They did not notice, because the field looked tidy the whole time.
Then a second report arrived. A user pasted an amount copied out of a bank statement, and it came with a non-breaking space between the thousands and a minus sign that was not the ASCII one. The field rejected it. They retyped it by hand, got it wrong, and opened a support ticket instead.
Both reports came down to the same mistake: the field rewrote text while the user's hands were still in it.
So in amountfield, our open-source input, we hold to a few rules now.
We do not reformat while you type. Grouping is applied on blur, once the person is done.
Half-typed input is a state rather than an error. "12." is on its way to "12.50". A group of two digits has simply not reached three yet. Neither of them deserves a red border.
When we do rewrite the text (grouping on blur, or removing a pasted symbol), the caret goes back after the same digits it was after before. Not to the end of the field. After the same digits.
A paste gets cleaned rather than translated. Our own currency symbol or code and non-breaking spaces are stripped, a non-ASCII minus is normalised, and a foreign currency symbol is refused outright.
That last rule is the part we argued about. Quietly reading a pasted euro symbol as our currency would have made the field feel smarter and the number wrong. With money, asking the person to fix the input is probably the cheaper failure.
It is worth checking where your own input layer still rewrites text under the user's hands.