This seems like an issue in Modem Manager API design issue. ofono and fsmgsd does it correctly.
A fix would be “either introduce some persistent storage of chunks, or design and API that lets an external process handle and acknowledge CSM as they arrive without buffering on SIM.”
As suggested by @dos
I can confirm I still have the problem on Crimson 
My child’s teacher sent me two messages today (or maybe just one, I don’t know) and I don’t know what she wrote.
On the first message, the phone was suspended and I saw the message woke it up (screen turned on, wifi connected a few seconds later; no visible notification, but I saw the dreaded (receiving) when I ran mmcli).
However I just made a test by suspending the phone (using the menu from the “power” icon) and sending a message from my wife’s phone, and that time it worked fine. Maybe it’s non-deterministic, or maybe it depends who sends the message..?
By the way it seems very much related to which provider you have. I’ve been having these stuck SMS problems ever since I changed to another provider. With the previous one it’s always been fine.
SMS is not a reliable protocol, messages can get lost just because the infrastructure had a bad mood that day. That’s the first thing to have in mind.
Second thing is that an SMS is limited to 160 characters (or less, depending on encoding). If you send a longer message, it gets split into several parts.
Third thing is that ModemManager does not expose a message to lower layers until it receives all of its parts. Until that happens, it’s seen as “receiving”.
Forth thing is that ModemManager relies on SIM storage to retrieve incoming messages. Lower layers, such as Chatty, grab a complete message from there and delete it from the SIM after processing. This doesn’t happen with “receiving” messages, as these are still waiting for some of their parts to be delivered. This also means that if the SIM storage is full, you can’t receive more messages until you make some room for them.
Combine it all together and you’ll have a pretty good mental model of the issues you’re seeing.
Fifth thing is that ModemManager do not support RCS. 
I was surprised that MMS work on Suspend Mode. To me SMS and MMS, CALLs work much much better on Gnu Crimson.
Oh, and one more thing - with SMS, due to various hiccups, the sender may get a network error even though the message has been actually sent and retry sending a message that was already sent. The network may also deliver multiple copies of a message that was sent only once.
If this happens to a multi-part message, you may end up correctly receiving and processing the whole message first, and then receiving a duplicate part of it which will now be stuck as “receiving” as it will be missing the rest of the parts forever.
You can still read the contents of the stuck parts that are stored on the SIM, but you need to use either AT or QMI commands directly as IIRC the MM API does not provide a way to access that.
Incoming MMS is signaled using an SMS, so there’s nothing surprising in that.
Interesting, thank you! I knew about long messages getting split (from the days we had to pay for every single sms) but did not think of that.
So, on my phone:
Somehow I don’t think space (sim is recent, only ever used in Librem 5) or infrastructure is to blame here.
Is there a way to see the text of a partially received message? Like if the first part out of three has been delivered?
Thanks!
Oh that’s interesting, I’ll investigate about that. Indeed I didn’t see anything in mmcli to retrieve message text. Just metadata with sender number and timestamp.
Is that reliably reproducible?
There was a time when SIMs have provided plenty of space for messages, but as most phones haven’t relied on SIM space for many years now, these days it’s not uncommon for SIMs to only provide 20 message slots as they used to long time ago (I wouldn’t be surprised if that’s the minimum amount required by the standard).
Sixth thing is: The sender (assumed not to be a Librem 5) may decide to use MMS rather than SMS based on the attributes of what it wants to send, including, in my experience, not so far listed here, depending on the number of recipients i.e. one sender sending to one recipient may differ in behaviour as compared with one sender sending to multiple recipients.
One of feature that i really, really, really, i want, i wish, i wait, is real SMS Encrypted on Chatty.
I mean Security(offline)SMS from Chatty to Chatty.
Please please @guido.gunther i know you have the power to do to finish.
That’s going to be difficult though because
But sure if you have a single pair of cooperating parties who have already exchanged key material securely outside of SMS and have agreed on what implementation to use and you don’t mind significant inconvenience … you can encrypt outside of $Chatty and then paste in and then send … and the receiver copies out and then decrypts outside of $Chatty and that will work - and I put a dollar sign in front of Chatty because the same works just fine with any messaging implementation (which is just being used as an insecure transport).
Yes it work, but not easy like native.
Yes I repeated the experiment a couple of times. All multi-part messages sent while the phone is awake were successfully received. All multi-part messages sent while the phone is sleeping were lost.
As an additional experiment I sent a multi-part message while the phone was off, the message was received correctly as soon as I turned it on and entered the sim pin.
So for now I’ll disable suspend, hopefully I won’t lose any more messages now.
Then please gather up logs and report the issue. I can receive multi-part messages while suspended without any issues on my phone.
Yes I’ll do that when I have both time, and access to my wife’s phone for sending test messages 
. Is Librem5/debs/ModemManager the correct project for reporting the issue?