Such a change inhernetly causes widespread disruption.
Again, you are assuming what you are trying to prove, which is no way to
argue.
This is a decision that has to be based on engineering judgement.
There's no way to "prove" whether any particular choice will be
successful or not because you can't adequately model the real-world
conditions.
Ned said, right at the start of this thread, that introducing UTF-8 was
not inherently hard or difficult, but that there were a certain number of
problems that would need to be tackled, amongst which would likely be a
suitable means of falling back to a 7-bit encoding.
It's not difficult to define how it would need to work, and it's not
particularly difficult to write the code. Introducing the code without
significant disruption is extremely difficult, and the benefit doesn't
justify the cost.
So yes, it would have to be introduced with care, and tradeoffs between
various approaches would have to be looked into.
But the way forward would be to examine the problems to find ways to work
around them, rather than to declare in advance, without proof, that is is
impossible.
No, that's not a way forward, it's a way backward. Because by trying to
force a transition to pure utf-8 you end up not only increasing the
complexity of MUAs but also of the MTAs that have to negotiate and translate.
And by putting this translation at additional places in the signal path
you decrease the liklihood that the message will arrive intact.
Many implementations today can't even encode RFC 2047 correctly. So how
can we expect tomorrow's implementations to translate correctly between
UTF-8 and IDNA+2047?
Keith