This naming problem seems to be common in areas with several large and roughly-similar solutions. Those similarities complicate the "use a descriptive module name" guideline that we'd otherwise aim for. (For example, if people didn't use project names like "Maypole" and "Catalyst", how many modules would we have with almost indistinguishable names like "Web::SimpleMVC", "Web::NiftyMVC" and "Web::FastMVC"?)

I think that the simplest step is to start by moving Tangram under a descriptive top-level namespace like DBIx:: or Persistence:: so that people who see the name at least have some basic idea of what it does. To quote from perlmodlib and perlmodstyle:

• Please use nested module names to group informally or categorize a module. There should be a very good reason for a module not to have a nested name.
• Avoid starting a new top-level hierarchy, especially if a suitable hierarchy already exists under which you could place your module.

For what it's worth, the DBIx:: namespace does seem to be well known, and it's where I put my own DBIx::SQLEngine. Changing the name to DBIx::Tangram seems minimally disruptive, and people who were looking for it under the old name would quickly find the new one.

If you want to go further, here are a few more naming tips from perlmodlib and perlmodstyle:

• Generally the name should reflect what is special about what the module does rather than how it does it.
• Always try to use two or more whole words.
• To be portable each component of a module name should be limited to 11 characters.
• Be consistent with existing modules.

Based on those suggestions, I'd be thinking of something along the lines of "DBIx::OrthoganalPersistence" or "DBIx::PersistenceMapping" -- those examples are both too long, but at least when you see them you have some idea of what the module does.