Kmail2 gives a false report that it has finished importing mail.
** Other unexplained bug reports about mail disappearing could be related to this systemic bug.
  The illusion is that Kmail2 has imported your mail into your mail directory, when it has in fact moved it to the akonadi database which may or may not succeed in exporting your mail or some of your mail to your mail diretory over the next few hours or days.   The result is that people can & do lose some or all of their mail if either the process or the database are disrupted before the slow process is finished.

Reproducible: Always

Steps to Reproduce:
1. Have over 1 gb email in a non-kmal folder or mbox
2. import the import mail

Actual Results:  
Kmail2 import functions move your email onto the akonadi database instead of your mail directory. Also as Kmail2 puts your email in jeopardy on the akonadi database, the import dialogue tells the user/victim that 100% of the mail has been imported and that the importing is finished. For hours or years afterwards your system becomes unresponsive and clogged up with unexplained akonadi activity while your email remains in jeopardy and will disappear if either the process or database are disrupted.

Expected Results:  
Kmail2 imports email to your mail directory.
If importing mail requires a temporary staging area, that it would use /tmp and NOT a database!

This appears to be another example of children wanting to use databases for things that should not be on a database. Its arogance to assume previous programers decided against using databases because they failed to understand how fast databases can be; with experience you too may learn that things like configuration & storage files should be kept on disc and not in a database that is open. It's been going on since the 1980s, people design good systems and then next generation of programers foul it up with inappropriate databases. Databases are great in their place and a menace outside it.