A couple of points for the discussion:
1. I thought that one of the requirements for successful module review was that it completely cleaned up after itself upon deletion, leaving no orphened records, etc. in the database tables.
2. Because of the problems that foreign key constraints on core tables could cause, I was very reluctant to use this route, but saw no real alternative and followed the example of several core team/project team members. The suggestion to use the scheduler is a good one, but adds an extra degree of development time and knowlege that most developers may not persue. What about adding a SQL trigger on a core table?
3. The reason that "nickka2" may not be seing records deleted in his custom tables when the module instance is deleted (even though he has enabled cascade deletes), is that when a module is deleted from a page, it is placed in the recycle bin. I don't beleve the cascade delete would occur until the recycle bin is emptied of the previously deleted module.
4. We really need to be able to run custom cleanup code upon module deletion and need to be able to hook up a method (probably in our business controller class) that will be called just before a module is finally deleted from the recycle bin (while its ModuleID is still valid) - similar to the UpdateModule method provided in the IUpdatable interface.