I'm not sure I understand what you are proposing ...
Currently we store a row in the blocks table for each module/delta/theme/region combination. This allows separate configuration of blocks by theme--a block can be enabled in one theme but disabled in another. That seemed like a good idea when we introduced the functionality. But it turns out that, if you have, say, 10 themes enabled, it's next to impossible to get your blocks configured evenly across themes. To enable a new block on all themes, you need to visit and submit 10 different screens (one for each theme). The result, on most sites, is a table with many near-duplicate records--they vary only by theme and/or region. I'm suggesting we normalize the table. We would end up with two tables. One is our existing blocks table, minus the 'theme' and 'region' fields. The second, block_theme, has the 'theme' and 'region' fields as well as module and delta. There are (potentially) many records in block_theme for each record in blocks. For the UI, the basic block configuration would be done only once. Just the region placement would be theme-specific. That's more or less what I've done in the blockregion module. It uses form_alter to change the default theme's block configuration page into a page for overall configuration of all settings. Then each additional theme's block configuration page is limited to region placement. I've added a screenshot of a non-default theme's UI: http://drupal.org/project/blockregion