[eluser]WanWizard[/eluser]
There are several prefixes at play here.
The first one is the one defined in the CI database definition, and is used application wide, and that includes Datamapper. You use this prefix if you store non-CI-app tables in the same database, and you want to make sure you have no collisions.
The second one is the one defined in the datamapper config file. It will be applied to all tables accessed by Datamapper through the models. It is mainly handy if your application has a mix of Datamapper and non-Datamapper tables, and you want to separate the two (again, to avoid collisions).
In this situation you might want to use the per-model prefix to override the second one, usually to set it to "" (empty string), so the model can access the table without Datamapper prefix (for example because it is a table shared with the non-DM part of the application).
I have never encountered a situation where the per-model prefix was used to set some other prefix. The only use-case I can think of is that you have several Datamapper driven applications using the same database, no CI prefix is defined, and the global Datamapper prefix is used to separate the application tables. You can then use the per-model prefix (for example for a users model) to share tables between applications by setting the prefix for this model the same in all applications.
I don't have a problem using some second 'prefix' in the table name to group tables within the database. I usually do that in a modular design (I prefix with the module name), again to avoid collisions. For an authentication module, I would indeed have table names starting with 'auth_'.
If the CI prefix is then 'CI_', the Datamapper prefix 'DM_', the table name would be something like 'CI_DM_auth_users'. I can live with that (it makes it absolutely clear what it is), and I don't really have a problem with the fact that this would create 'CI_DM_auth_groups_auth_users' as relationship table. If you have an issue with this, you can name the relationship table using the 'join_table' field if you use advanced relationship definitions.