If this is related to retweeting/@replys/etc then you can understand why the "bug" exists. Since the users rather than Twitter came up with the RT concept Twitter only envisioned tweets (they didn't even invent the term tweets) as text with no metadata. If, for the purposes of expanding the service they wanted to mark each tweet with some secret metadata that is stripped out on the back-end it is too time-consuming to add the attribute to every tweet (they are on MySQL if I'm not mistaken) so they come up with a syntax for the metadata, write some code to filter tweets that inadvertently use that syntax, and start using that syntax behind the scenes in preparation for new or more efficient implementation of features.

Theory 2:

Or maybe it is just related to their templating system.

[Addendum]

Either way I find it kind of sloppy. It would not be that difficult to escape text in tweets that marches your syntax. Web apps should avoid revealing anything about their internal workings. This is how XSS attacks happen.

  Fe, Fi, Fo, Fum.
  I smell the blood of an eval call,
  Be it abstract, or be it concrete,
  I’ll grind their strings to mix my syntax.

After some experimentation with my test account, it looks like it's actually (re *) that gets stripped out. I wonder if it has to do with replying, or retweeting

If not, there really should be.

"(re)" causes the page to hang

"(re)bleh" results in "bleh"

I decided to see if nesting or prepending it multiple times would work:

"(re(re))" produces ")", so nesting doesn't work.

However, "(re)(re)" produces "(re)", so it seems you can slip it through just by prepending "(re)" to the message.

So if this was supposed to filter something, it's pretty easy to get past. If I just knew what they were trying to filter, this would be more interesting. :)

It was meant to filter out some text added by cell phones to replies.