the bug is reported against digikam master

Images and albums are not deleted within the database (mysql) when they're (re-)moved. Following example:

One collection (digikam5-test) with one album (dir1) and one picture (crop_000010a-fixed.png). 

the Albums table contains two entries: 
id 1; relativePath /
id 2;  relativePath /dir1

the Images table has one entry:
id 1; album 2; name crop_000010a-fixed.png; status 1

Now creating a new album dir2 and moving the picture there:

the Albums table contains three entries: 
id 1; relativePath /
id 2;  relativePath /dir1
id 3; relativePath /dir2

the Images table has two entries:
id 1; album NULL; name crop_000010a-fixed.png; status 3
id 2; album 2; name crop_000010a-fixed.png; status 1

Now deleting album 2 with the picture:

the Albums table still contains three entries: 
id 1; relativePath /
id 2;  relativePath /dir1
id 3; relativePath /dir2

the Images table has still two entries:
id 1; album NULL; name crop_000010a-fixed.png; status 3
id 2; album NULL; name crop_000010a-fixed.png; status 3

The image and the directory (dir2) are deleted within the filesystem. The images is also gone in digikam. I think the reason for this is status 3 or album NULL. The album (dir2) is still shown in digikam with no content.  When selecting it, digikam shows the error when started on commandline:
digikam.database: Folder does not exist or is not readable:  "/home/pictures/digikam5-test/dir2"

So at least the handling of deleted albums is broken. But the whole handling of deleted items looks broken to me. Why are they kept for all time within the db? A picture or album removed from the collection has to be removed from the db too. A moved item has to be updated, not inserted new. At moment, the database is growing with orphaned items nobody will ever need again.

I didn't had the problems with still shown albums after deletion with digikam4. But I think the problem of newly created db entries with every move of an item already existed there.

Reproducible: Always