That's...a terrible idea. You're now bound to a specific subset of editors that are capable of producing ⇒ (as opposed to the two-character => ), for...for what?
For looking pretty, I assume: that's probably a matter of UI (editor displays arrow character instead of equals+greaterThan), but should not propagate into actual source code.
And now you can only type code in the set of blessed editors and correctly displaying fonts. "Make code pretty" should be a matter of presentation, not actual source code.
To use your example, typing "=>" could display the "follows" sign, but the string representation should not depend on exotic characters like "ř", "⸙", or "" (is that a box symbol, or "symbol not found in current font"? Oh wait, the HTML input field ate it! See?!).
In general, I agree with the principle: presentation and source code are not tied together. But we've been constrained to ASCII for programming for far too long. Sure, there are benefits, but is there a way forward? How can we know if we don't explore it.
Most development IDEs are configurable and extendable in such a way. Or well, at least the one I am using is (Emacs). Just like opinionated languages have not had those choices stop them from becoming widespread (eg Python re indentation), so shouldn't the character set used either.
You could also redefine your keyboard layout (eg. a happy hacking keyboard has no marks on the keyboard) or come up with a programming input method (IM) to use — not everyone would have to do it, someone would make it and others would use it. But making wider use of the characters available has to start somewhere, and it can't start with input systems (before there's a widespread need for them).
Sure, it's possible, with major compat breaks. What I'm asking is this: what is the (commensurate) benefit from this change? I just don't see "looks prettier by default" as a strong enough reason - what am I missing?
Unicode and its transformation formats (UTF-8, -16) were major "compat breaks", and to be honest, still are. We did not push for them for the emojis, but for the ability to be more precise and more expressive.
Mathematics has developed a very large alphabet for the very same reasons, and if it was constrained to ASCII, we'd be learning integrals today in the "Newtonian way".
If you don't see those properties as offering any benefits to a craft that is based on precision and that has new languages popping up regularly to cater to new expression forms, that's fine. I still believe it's an unexplored area, and we'll only see benefits once we start to make heavy use of the advances.
Quite the contrary, UTF-8 is backward compatible to ASCII...it was a compat break from the local character encodings.
As to mathematics: do you imply that using a wider charset is akin to completely new mathematical methods? Or that a symbol needs to be one character? Both sounds implausible, I still must be misunderstanding...
Sure, UTF-8 is backwards compatible with ASCII, but as you figured out, I was referring to all the 8bit encodings that were in widespread use (eg. HTTP defaults to ISO-8859-1/latin1). And even with "pure" 7-bit ASCII, there is still no reliable way to send an email to неко@негде.срб. You may believe that there are no compatibility problems, but I disagree.
As for maths, I was referring to the fact that notation (signs we express ourselves in in writing) matters, and that further advances in calculus were enabled by using a nicer and more concise character set vs doing everything with "fluxions" and "fluents". You seem to insist on keeping us restricted to ASCII, whereas I am open to exploring new approaches without understanding if there are any benefits first (I am not focused in RoI :)).
This is a nice feature of APL, and the derivatives such as J which use plain ASCII are much less nice to work with.