When enabling the column "Size" for the treeview of folders (via the RMB context menu), the width of that column is enormously large, also cannot be resized to something smaller it seems (tried by scrolling the view to the right & grepping the right size of the "Size" column header, but never reached a smaller size, despite all flickering which would have hinted resize happening).
This makes the "Size" column unusable, as the numbers will be always out of view.
The other columns behave as expected, starting with sane size & being resizable as wanted. Enabling & disabling all combinations of columns did not have any effect, the "Size" column always was with that insane width, and only it.
STEPS TO REPRODUCE
1. Run KMail
2. RMB on header of folder list tree view
3. Enable column "Size"
Column "Size" added having immense width, resulting in minimal small handle in the horizontal scrollbar. While the list header shows the left aligned "Size" label still the inside view (when folder list view accordingly sized), the size values are right aligned in the actual column area and thus out of view, unless one moves the horizontal scrollbar to the very right, and thus no longer seeing the other columns.
The column "Size" should appear with a sane initial size, and be resizable to what the user prefers. So that it is possible to see all columns at the same time.
KDE Frameworks Version: 5.66
Qt Version: 5.14
but seen also before since ages, should have reported earlier :) )
I looked around in the respective codebases, but could not find a reason why such a large minimum column size was calculated, also could not reproduce in a separate account.
I then removed the State entry from the [CollectionFolderView] entry in kmail2rc, restarted kmail, and the issue was gone.
So seems Qt had some internal bad state encoded in that data blob which enforced the insane large column width, possibly some incompatibility acros versions.
Sadly I lost the value of the State entry, so also cannot try to investigate where Qt might need fixing.
Thus just closing now, as it seems no bug in KDE code :)