I can confirm:
WRT to the logs you requested:
I enabled TB logging, created a new mailbox, a new ThunderBird profile and configured it; I sent it a new message with a 64kB attachment and it showed as 32kB!!! Saving it, however produced the correct 64kB file. I'm attaching the log.
I quit TB, disabled logging and rerun it: now the attachment was marked correctly as 64kB (???).
Since I previously said a new profile didn't solve, I tried again: creating a new profile, connecting it to one of my existing mailbox and descending into some folders, I cannot save attachments.
I'm so puzzled...
In any case, back to my old profile, I did some research WRT the minimal attachment size which will trigger the problem:
_ dd if=/dev/zero of=a.pdf count=1 bs=20480
_ send a.pdf to myself
_ the attachment can be saved (of couse I cannot open it since it's not a valid PDF).
With "dd if=/dev/zero of=a.pdf count=1 bs=21540", "size unknown" is displayed and the attachment cannot be accessed.
I could not reliably determine the exact threshold: probably it's not really the attachment size that matters, but the whole message size, so some small difference in headers can change the behaviour when the file is between 20 and 21 kB (corresponding to a received message size around 30kB).
Incidentally, I was also surprised to see that the problem goes away if I name the attachment a.dat (instead of a.pdf)!!!
If in a single message I attach both a.pdf and a.dat (same zero filled content), I can save a.dat (whose size TB correctly identifies), but not a.pdf (which is, again, marked "size unknown").
Back to the 30kB limit, I saw mail.imap.mime_parts_on_demand_threshold defaults to 30000. Raising this, raises the size of PDFs I can open/save.
So, unless raising it to 10000000 has some nasty side-effects, this could solve my problem.
I would also expect setting mail.imap.mime_parts_on_demand=false would achieve, but it doesn't.
Instead, setting mail.server.default.mime_parts_on_demand=false does.
(I tried this before and asserted on the ML it didn't work... either I had done something wrong or an update has changed something meanwhile).
Last thing for now, I realized FreeBSD's 68.0_1 package is build from RC3. Now 68.0_2 is out, which is based on RC6. I'm currently building it.