Unexpected Twinkle username restrictions.

ed, excellent! Glad to hear I will get to use it again! (Pretty tied to making the "si" look like the atomic symbol for silicon.) ( Delete or Edit)

What bugs me most is that there is nothing "special" about characters like spaces and brackets, and I see no reason to reserve characters for mutable, public-facing names. (Static, unique identifiers are another story.) It appears Twinkle user names do not line up with those in Twitter, so I do not understand imposing similar constraints. Naturally, I am speculating here and I am not trying to slam the developers (their work is absolutely outstanding, and their participation here is above and beyond). But, I believe tightening restrictions after the fact is harmful to usability. The "least surprise" principle is important to follow. ( Delete or Edit)

Oh, not at all pissed! Again, I think Tapulous has some excellent engineers and great products, and I cannot be angry that this free product does not work exactly as I wish. Just trying to provide the developers with some constructive feedback about how users are affected (although, possibly being too vocal about it). To put this another way, dialing back functionality can confuse and frustrate users. It is risky even when done to satisfy practical engineering concerns. ( Delete or Edit)

Ah-hah, that makes total sense. (Now here come some rambling ideas.)

I thought rainbow table resolution would fix that case. However, naive algorithms that progressively test possible usernames can fail when names with prefixes exist and within certain messages. To elaborate on your stated case: assuming users "John Smith" and "John Smith Jones", messages like "@John Smith Jones called and says 'hello'." defeat resolution. (Is the user addressing "John Smith" and discussing "Jones" or addressing "John Smith Jones" and discussing an implied subject?)

Perhaps when publishing their tweets, users could be prompted to manually resolve ambiguities? (I am tempted to believe this edge case is rare.) Considering the previous sample message, users could be prompted with dialogues containing spinner controls that list possible matches. Another option, although I think less desirable, might be augmented autocompletion. That may, however, require hidden control characters to delimit the resulting username from the message.

Naturally, there are big downsides. This may all incur excessive database load. (At least with Twitter, far more writes occur than reads, leaving little room for any additional access overhead.) The additional network roundtrips also increase chances for the transaction to fail. ( Delete or Edit)