<sarcasm>Oh yeah, that's right</sarcasm>
That's a contingent answer. If you, say, set out to try to convince the world to use it that way, and created that demand, then by golly, that demand would exist at that point and the answer could change. But hypothesizing some possible text message that could use it isn't strong enough to argue for inclusion in the standard because every possible proposal passes that test.
Phones already do it for .com, .gov, etc, but our cutesy .sh, .dev, .rocks, .xyz, etc will take a bit to catch up.
Negative. My renderer is a piece of paper.
The request is for a code point to represent the visible external link character, not for an invisible control-code to decorate some structured data (which cannot "appear" on paper).
(The hsts preload list helps a bit with this, but only for domains registered with it.)
I accept that heuristic, and find myself agreeing with it for the purposes of the external link character. Let me try to convince you:
This is a real conversation:
A> Are you familiar with Homebrew? You can get it from brew.sh.
B> Ok. Where is brew.sh?
If we were not limited by plain text, we could use colour and underlining to distinguish that as a domain name. A lot of websites find this poor for accessibility reasons so they use the link character.
Another way to think about this is to imagine the link-character is pronounced "https://" as in:
* Are you familiar with Homebrew? You can get it from https://brew.sh.
* Are you familiar with Homebrew? You can get it from {link character} brew.sh.
Isn't that plain text? I'm not sure how to pronounce it, but there's a lot of emoji I don't know how to pronounce. Do you think this is important?
So if you get that far, how much further is this really?
* Are you familiar with Homebrew? You can get it from brew.sh {link character}.