I'm seeing a big picture of a lot of issues solved in a single way here. People want to slightly adjust how the type mapping works in various ways - and I think we can do a better job of allowing this.

Here are some examples:

• Added Column attribute - to alias column names #376 Changing the mapping using a [Column] attribute (I'm thinking [DataMember])
• create overload Query<T> to customize the mapper #360 Customizing the Query<T> mapper
• Automatic multi mapping : would this be possible ? #350 More automated multi-mapping
• Dapper isn't mapping correctly #326 An Azure-side issue with Id columns that could possibly be worked around
• Mapping of TimeSpan to DbType.Time is too restrictive #319 Changing how TimeSpan maps
• option to throw when result set has unmapped columns #254 Option to throw with unmapped columns (use cases for both directions)
• advice about Colmap #251 Colmaps for Oracle
• Please add support for Nodatime #198 Supporting Nodatime

This one is a more questionable example (as in questionable if this would help):

• Querying abstract types #262 Query abstract types

There may be a few I missed, but you get the idea. You can replace the DefaultTypeMap since #110 was merged a few weeks ago. However, we can do better here by allowing DefaultTypeMap to be plugged a bit rather than clipboard inherited all over. We'd also need to look at what functionality could move down into it to be pluggable (such as column names).

I'm not arguing for this to all be in core - I honestly think it'd be a bad idea if all of it was. I think making it pluggable makes some of the odder cases, if common, appear as mappers you could easily plug in from contrib. For example, what if #376 could be fixed by:

SqlMapper.TypeMapProvider = t => Dapper.Contrib.DataMemberMapper;

and #350 by:

SqlMapper.TypeMapProvider = t => MyCustomMultiMapper;

Posting this here for thoughts.