Essentially a tweet ID should be a pointer to "latest version", but with historical versions preserved and available at the same visibility level as the parent (typically public) and a small indicator would show that it has been edited and the history is available.
But all of those, "Damn I made a typo or dumb spelling (thx mobile keyboard) and yet it has been replied to or re-tweeted already"... all of that is solved by edit with visible history.
I write "I love cats!" You RT it. I edit it to "I am Al Queda." The FBI visits you.
Case 2:
I write "I am Al Queda." I edit it to "I love cats!" before you see it. You like cats, too, so you RT it. The FBI has a slow feed, so they see that you endorsed my Al Queda membership. They pay you a visit.
---
From a systems point of view, when your whole stack is designed around immutability (so you can serve archives of past tweets from append-only CDNs, for example) it may be nigh impossible to add editing.
I think it already happened with a troll baiting racists. He waited for a lot of RT then changed the source of the embedded racist picture with something like "I am a big disgusting stupid racist". Something like that. It was a good one, though.
Just imagine the gargantuan changes that could be necessary for small tweaks like that. Twitter was built on RoR originally, so it was probably a pretty standard relational model, then they did massive scaling for huge read/write loads, then they did massive scaling for real time features, god knows how hard it would be just to add a foreign key. I really, really, want to take a day and just go through all their engineering blogs after only glimpsing a few..
Honestly, if they only designed to scale and did not anticipate iterating on the product, they deserve to fail. My guess is that this not a trivial change but worth the effort.
