Reversion in number field input behavior

I’d like to be sure this is not just me. Simply put, number (either integer or float) fields in Pan 10.2 don’t accept input with thousands separators, but fails with a “not a valid floating point value” type of error. Values like 1,234 or 1,234.56 require re-editing, whether pasted or typed in.
I seem to recall this behavior early in Pan X, but it was fixed quite a while ago.
It’s a small problem, but puzzling to see this again. Or has my computer launched a vendetta against me? (Mojave, 10.14.6).

Confirmed. Panorama X 10.2 doesn’t allow the thousands separators. Panorama X 10.1.2 does. This appears to be deliberate given the very detailed error alert.

Thanks, Dave. I can rest easier knowing it’s not a plot…
I wish it would go back. I often copy numbers from web sources, etc., and paste them in with the commas present.
As I said, probably not the top of the list!

You could write your own “paste” routine that strips the comma out first. But … if you are dealing with numbers from other countries, I think a comma is used were we use a decimal point. So your strip action might need the addition of checking if you have an option key down or some other indicator to handle that special case.

It is true that I could fix the number on pasting (val() is pretty simple). I could also just edit the input. However, I am puzzled because the missing behavior was considered a feature, newly implemented in Aug. '18 with the release of 10.1 (from the release notes):

When entering data, importing text, or converting text to numbers, strip non-numeric characters before converting text into numbers, so that currency symbols, etc. are ignored. In other words, you can now import numbers like $3,456.12 without a problem.

It makes me think that this was not intentional, so is something else broken?