The installer script does already table name replacements. So, I don't see a reason why is would be complicate to extend it for configurable database names.
It does this only for known tables (these in initial schema file). So, for your case of dynamic table names it will not work. Besides that, one option (prefix) is better than a mass of separate options (for each table).
Is this really a valid argument? The plugin developer has to take care about schema updates of plugin tables. In my example: If I duplicate cache tables for a plugin I have to take care that these tables are updated when you change the schema in core.
The real problem with the prefix is that it refers to ALL tables in the database. The advantage of the previous/removed method is that it can be used for single tables.