We use Mark Sandy's approach as well.  Many of our stored procs deal with one table, and so the Module_Table_Action has worked EXTREMELY well.  If you want to see which procs are acting on a table, its very easy to find.

Even better, when training someone else on the architecture, it takes all of 5 minutes for them to comprehend - the ultimate in sustainability. 

Since I also code on the client side, its made that part simpler as well.

The last thing I'll mention is that the unique identifier for a table I always make the table name + "ID", e.g., CustomerID for the Customer table.  Makes running queries by string concatenation really useful.  Once I know my table name, I know that the proc to retrieve information is RPO_[TableName]_GET, based off of ID [TableName]ID.

I can't say enough good things about this technique.