Say someone uploads an image, it sits there for a few weeks, and they then go in an DELETE the image from their post. Is the image still on the server? Or does it delete from DB and host as well?

The image is deleted both from the database and the server since iWiccle 1.11. When you delete a post, attached images both from Associated Image and the Sidebar Uploader can optionally be deleted -- you get a checkbox for deleting "all associated media". Both the original image (if it was opted to be saved) and the auto-generated thumbnails will be deleted (provided scaled sizes haven't been reconfigured in between, in which case only thumbnails of the current configuration are deleted).

This does not yet extend to posts' media being deleted when a thread, a category, or a parent-level container is deleted. This will be addressed in an upcoming release, and there will also be maintenance tools under Admin CP > System for searching and cleaning up abandoned uploads of different varieties retroactively, and with preview before delete option. (Integrated Clam Antivirus support will also be introduced shortly.)

The aim is to support complete recursive deleting of all associated uploads across all container setups, as well as for past and present image scaling configurations. This is already happening with posted data and the different containers, as the entire content tree gets deleted when a higher-level container is deleted.

I will need to revisit the posts-per-category counters etc. across all container-change and delete situations, to see that they scale to decrement and increment the correct containers' counters in each distinct module configuration. It seems to be working fine, but it appears there are some ways in which things can still go out of sync. There will also be a counters' synchronization tool in a near future release to cover the bases before things are refined further.

Ideally there are zero clutter and no abandoned data in the system at any time (or a purge at set intervals), as it keeps both your database and your filesystem slim and happy, your backups quicker and smaller, and the possibility of malicious files (such as the ever-so-common backdoors dropped in after a hack into one of those huge folder trees) hidden in the abyss of the upload folders minimal. Security and performance, two simple arguments in favor of investing time in this. Since all the data in our system is symmetric and categorized, this is easy enough a milestone to reach over the coming months alongside other development.

We also intend to add in easy-to-configure cron tab task support for running some of the key maintenance tools on scheduled intervals to keep the site further optimized. These options will be available in both iWiccle and Wiccle whenever the development reaches a milestone. Even if they are a bit in the high-end department and more in the profile of the Wiccle Web Builder release, they will go into both builds as they are something that's very integral to our design philosophy of creating products that are slick, simple, clean and compact across the board.