On that report it seems that they were taking the url parameter
reported_tweet_id and copying it into a HTTP header (likely inside a Location, as part of a redirect) after a faulty transformation.
As Steffen Ullrich noted, they somehow took the unicode character and left only the last byte, which allowed filedescriptor to bypass the check for a \x0a.
At the end of the report, the reporter asked for the root cause, which twitter declined to share, so we are left wondering. It's quite strange, since on the one hand, they properly decoded the unicode character (to utf-16, perhaps), while on the other, they completely lost the higher 16 bits. Maybe a faulty unicode library that after a unicode conversion, blindly assumed the result would be iso-8859-1 and copied just the lower byte. Note that they were injected into HTTP headers, which don't support utf-8 (or unicode, any non-ASCII character should be urlencoded there), which is what allowed the CRLF injection on this bug of extra HTTP headers and html body.