The conditions under which something inadvertently becomes Complex is relatively narrow and in my experience really doesn't happen often. Remember: I've been using a simplified variation of this for over 5 years now (one without the positive and negative real distinction), so this isn't some untested pie-in-the-sky idea. It works fine.
Yes, I also acknowledge that it would be great to have a more fleshed out version for Swift. You've seen my attempt at this, and I've documented some of the problems. But honestly, if there's no enthusiasm for it, it's a completely dead idea.
Parts of this thread remind me a lot of Comparable and FloatingPoint types (the digression about using the type system to get rid of nan) - and I can only repeat what I wrote there:
Wouldn't it be better to give the discussion about doing Math in a fundamental different way (compared to, let's say C) its own place?
As for the proposal:
I'd probably choose different names, but the one thing that's imho really remarkable is that this would finally add functionality to Swift that isn't part of the stdlib. This model could save hours of discussion wether an algorithm, operator or a type is important enough for inclusion - just stuff it into a fitting module (AdvancedCollections, FunctionalProgramming, VectorAlgebra…), and everyone could benefit from it.
I agree, I think we need to stop being afraid for even obscure unicode characters now that we have ditital keyboards and a billion input methods and strategies to get these characters into the sourcecode.
Even if we have an accessible way to input these characters (we don’t), we would still need programming fonts that support these characters. The most popular Swift font, San Francisco, does not. Fira and Source Code, which are probably the most advanced programming fonts currently available, support the digits [0-9], but not [A-Fa-fxo], which we would need since we would want any valid Swift integer literal to also work in a superscript setting.