Investigating on this..

I was able to replicate the issue with the following steps:

1. Have a contact with very large name;
2. Add the contact as the recipient;
3. Remove focus from the recipient edit text;

Video evidence:

After analysing the issue, it looks like this behaviour is handler directly by TokenCompleteTextView from Splitwise's TokenAutoComplete. We're currently using version 4.0.0-beta01 from Jul 15, 2020, and version 4.0.0-beta01 from Dec 15, 2022 is available (it might be worth giving the bump a try). I tried to bump it myself, but between these versions, TokenCompleteTextView.java was converted to TokenCompleteTextView.kt, and there are a few issues associated with this change such as:

• TokenImageSpan was converted to an inner final class, which is an issue because we extend it;
• TokenImageSpan.onClick() is also final, and we override it;

On multiple occasions Splitwise's TokenAutoComplete made changes to the modifiers on this class specifically, it might be worth opening a ticket on their board requesting that these issues are addressed.

I can confirm this +1 behaviour.
Sony xperia III, android 13

I'm getting the same issue. Not just for very large names, but also names/addresses that look like they could fit just fine:

Note: Since we used the TokenAutoComplete library in a very specific way that didn't always match what it was intended for, we included a copy of the library in our repository and modified it to better suit our needs.

The method responsible for "collapsing" the view is TokenCompleteTextView.performCollapse().

The logic on how many "tokens" to display is not quite right. It definitely doesn't reliably work for our recipient chips.

I believe a fixed version of the code would need to use the width of ViewSpan to calculate how many tokens can be displayed along with the "+X" text in one line.
And since we always want to display the first recipient token, the case where the token is too wide for the text field to also accommodate the "+X" text, we need to limit the width of the ViewSpan so there's just enough room for the "+X" text.

Fixing this issue could be done in multiple stages. The easiest win is to never attempt to collapse the view when there's only one recipient chip and no additional text. With #8734 merged, the text in the chip will be correctly ellipsized when it is wider than the available space.