You don't need RIGHT-TO-LEFT OVERRIDE to support URLs in right-to-left languages. It's an extremely rare codepoint that's used to force left-to-right characters to be displayed as if they were right-to-left characters. The only use case I can think of off the top of my head is some kind of interlinear phonetic transcription where you want Latin characters to flow the same direction as the corresponding Arabic for ease of cross-referencing.

For ordinary bidirectional texts, RIGHT-TO-LEFT ISOLATE, its sibling LEFT-TO-RIGHT ISOLATE and POP DIRECTIONAL FORMATTING are plenty:

⁧عنوان URL لهذا التعليق هو: https://news.ycombinator.com/item?id=38734329‬

Where I used RIGHT-TO-LEFT ISOLATE in the beginning to make sure the Arabic text in front of the colon is to the right of it, and then POP DIRECTIONAL FORMATTING in the end to restore the original directionality. (Amusingly, HN's URL parser treats the POP DIRECTIONAL FORMATTING as part of the URL, which breaks the link.)

Otherwise it would show up like below, where "in front of the colon" means "left of it" (as is customary in English text):

عنوان URL لهذا التعليق هو: https://news.ycombinator.com/item?id=38734329

You can only apply the fix to the URL field in the payload described, not to normal message text.

The client should probably be aware of whether the user might be expecting RTL text and maybe display a warning if not? Arabic users receiving a URL containing the character shouldn't raise any eyebrows, but if a random Anglo user clicks on one it might be worth displaying a warning that it's backwards text? At least the first time.