Good idea, but I think you need to account for "visible" (ie, if the newline is inside RL_PROMPT_START_IGNORE, it shouldn't change the width). It might be best to add logic inside the existing "if (visible)" instead of making a new top-level case.
Right, I assumed that it was safe given that only terminal control characters were invisible.
Since the title of the terminal window can be changed as well via control characters, it's probably better not to make that assumption.
I updated the patch accordingly.
Another special case that somebody's likely to whine about is \t, though to handle that we'd have to make assumptions about the tab stop distance. Maybe assuming that it's 8 is good enough.
The problem with tabs is that any user can set their tabstops to whatever they want, and a tab doesn't have a fixed width, it just goes up to the next tab stop.
One way to do it would be to add tabs wherever necessary in prompt2 to make sure they have the same size as in prompt1 (a list of numbers of spaces, which we would concatenate with a tab?), but I'm not sure it's worth the effort.