Facts are not arguments. People do what they need to achieve their goals.
The same rationale you're using could be used to defend edits, markdown, bbcode syntax, whatever. As long as enough clients support these things people will start doing them, then you can start claiming it's not realistic to remove support.
Your point about edits is hurtful and insensitive
I see a qualitative difference here, though.
There is no "users will do it with ____ expected result" when it comes to edits. If the devs don't add the ability to edit kind 1 notes to their clients, then users won't edit them, because they can't. Not without overcoming a significant technical barrier, at any rate; namely, building their own client.
Meanwhile, when it comes to users adding or not adding the `nostr:` prefix to Nostr URIs, I believe that good design includes the application producing outputs the user expects when they provide a given input that a non-technical user is likely to provide. The exception would be applications that are only built for technical users.
Is it likely that a non-technical user will paste in a Nostr URI without the prefix? Not just likely. It can be seen in countless examples. Indeed, it is the way users will naturally paste the URI, until they have been instructed otherwise.
Can users learn by trial and error and/or assistance from other users that they should add the prefix if they want it to work consistently? Absolutely! But to the degree that they are required to do so is the degree to which the application's UX is not intuitive. Better if an application updates the URI for the user. Better still if the app's UI notifies them of the update and why, with the option to turn off this "URI autocorrect."
Coracle already fixes the URL on behalf of the user, which is the correct implementation if you ask me. Damus also does this at least in part, and others I forgot. I think it's going to be well.
Jumble too.
Users should be warned though
On Coracle there is clear visual feedback.
It definitely shows that the event referenced will be treated as a Nostr URI rather than a plaintext string. That's probably enough, particularly since the user can preview how the post will be rendered prior to publishing it.
Jumble, by contrast, doesn't give any visual indication in the composition window unless you toggle over to preview how it will be rendered. I definitely prefer the way Coracle handles it.
