UPDATE: I checked the PHP repository and the offending commit was r288034 by Sriram Natarajan. What really pisses me off about this is that not only did he check it in despite breaking a test (ext/standard/tests/streams/stream_get_contents_002.phpt). But the change made it all the way into the next bugfix release despite breaking a test. The bug was fixed 5 days ago by Dmitry Stogov in r288604.

I can't say for sure if this is a problem on Facebook's side or a carrier issue. I've been reading a lot about congestion issues in regards to 3G, especially with AT&T. For the purposes of finding a solution though, it's not that important. The ways to mitigate the problem are mostly the same, it just the question of who implements them. In a perfect world, both sides would work on it, but as recent insights into the profit structure of the text message business show, cell phone carriers are increasing profits while keeping infrastructure investments flat for the most part.

Now, for all the importance that text messages are carrying today they are comparably unreliable. There is no SLA and as I mentioned, the infrastructure investments are lagging behind skyrocketing usage. At the same time, a high amount of messages associated with social networking and micro-blogging are both broadcasts and highly immediate. That means that their is no express expectation of delivery on the receiving end and that their perceived value drops sharply with delivery time. Therefor, paradoxically, the low expectation of reliability could be used to increase reliability overall by decreasing congestion volume.

This could be done relatively simple by attaching an expiration time to certain classes of messages like broadcasts. In the example above, a status update at 8pm triggers a text message to be sent to each subscriber. Now, I personally wouldn't care about a status update that's 2 hours late, but let's just go with a default expiration time of 4 hours. If the message can't be delivered by midnight, it gets discarded and purged from the sender queue. Odds are nobody would care about the information anyhow, and there's a good chance the receiver already found out since the same information is accessible in other ways.
Now, in my own example, since the message was sent at 8pm and I don't want to receive messages after 11pm, the expiration time could be set to 3 hours. If it can't be delivered in 3 hours, it eases congestion and I don't get annoyed by messages I don't care about in the middle of the night.