Yes, this is T5301, but the discussion was closed there without any real resolution being offered.
The first “solution” suggested is not a solution at all. If something is not actually code, it should not be escaped as code. This “solution” simply results in ambiguity.
The second “solution” involves adding a potentially unbounded number of objects to the global configuration for the instance. At best, it’s untenable. At worst, it results in being unable to link to actual objects on the instance.
The third, “discouraged” option is the only real solution, but involves inserting invisible, difficult to product characters into comments. This is at best user-unfriendly.
The discussion under T5301 seems to gloss over the fact that the entire reason this issue exists is that Phabricator is escaping sequences of characters intended to be reproduced literally, yet the only real argument against offering an escape sequence for these escapes (aside from dismissing numerous examples outright where this has caused people problems) is that people might insert the new escape sequence by accident. The argument boils down to the assertion that there shouldn’t be an escape sequence to correct a real formatting issue users of Phabricator are hitting because any theoretical solution would necessarily cause more issues of the same type.
While not technically wrong, this argument is quite circular and more than a little unconvincing. Properly implemented, an in-line escape sequence will literally be the solution to any problems it might cause, and just glancing at a nearby keyboard, I see plenty of character sequences far less common than a capital letter followed by a few numbers ripe for the picking.
This is a real issue your users are hitting. Let’s fix it rather than trying to sweep it under the rug with non-solutions because none of the examples your users have brought to you where this is an issue are somehow good enough.