I seemed to get a good rep on my call.
They found an existing case that this was a known issue. No ETA yet. But they're going to submit an escalation case looking for an update.
They did have some guidance:
Only submit ASCII characters 32-127 to Authorize.Net.
Apparently there is also some setting on the form to limit to secure chararacters.
In our case, the issue seems to be that two consecutive space characters (ASCII 32) get translated into an ASCII 32 + character outside of the range. We may try to update our integration to replace consecutive spaces with a single space.
Even if you limit what you're passing, if you're using free-form text fields as part of your check-out process (on the SIM page), you won't be able to avoid the user entering characters outside of the acceptable range.
Falling back to the old hash isn't a good option as they official stop supporting that on June 27th.
I'll try to update you when/if I hear back from the escalation team.