[I am speaking entirely in my personal capacity here and the forwarded email]
The letter does exist, and it would seem it was considered. Rather than pivot the point in that direction, what about the points I raise? These should be in focus.
The outcome in the time since my original email was a deferal, and current procedural step is a GNSO Council review with a small group of interested parties to determine if this is something that bypassed and needs a PDP, and under contemplation are different options forward such as splitting cc/g variant top level matters.
The concern I was voicing was entirely about backward compatibility - focused mostly about second level changes that may break or invalidate legacy innovators registrations.
Standards evolution needs to have backward compatibility. New standards have to ensure some manner to continue retroactive support for prior standards.
Why? Ĺet us be painfully self-authentic about IDN here... it holds potential, and can do big things, but the very pragmatic truth is that it requires developers to do extra stuff to make it work.
Introducing IDN support into project development is typically not a priority when weighed against other projects or features within most development teams. It adds scope and often needs specialized expertise, neither of which reduce cost.
If we are telling developers and registrants to take the time, money, etc. to prioritize IN and build something using today's standard... it needs to be sonething there is a reasonable degree of confidence in.
Here is an example. IDNA2003 vs IDNA2008 changed variant support and it rendered some changes that developers still lament.
If you are someone who went to embrace IDN, with all of its development overheads I describe, and in 2003 registered a perfectly valid registration and started using it, and 5 years later in 2008 you wanted to register (say for brand protection purposes in this example) that string, it may or may not be possible.
The standard evolution may have meant it became a variant of another string or worse was rendered invalid. That is a bad experience.
In the case that the name was impacted, that perfectly valid registration from 2003 becomes harder and harder to use due to development being focused upon 2008's standard.
We certainly learn as we go, and in parallel the Unicode Standard, security concerns, browsers, ca, other things evolve over time.
Invalidating a registration or otherwise failing to provide reliability and stability completely undermines institutional confidence.
As we evolve the standards, if we fail to support those who innovate as we evolve, do we undermine confidence?
Is it a reasonable expectation that those who would take on that extra overhead of IDN adoption do so where we are providing evidence of later potentially breaking it?
Let's be honest, they will likely just find lower risk areas to focus their resources and skip it.
-J