In 1.6, the design of the convention system for automapping BsonClassMaps is fixed and can't be extended. For 2.0, we are redesigning the convention system to be much more flexible and extensible. See the following new interfaces and classes for details:

IConvention
IConventionPack
IClassMapConvention
IMemberMapConvention
IPostProcessingConvention

ConventionPack
ConventionRegistry

The general idea is that ConventionPacks are registered with a filter lambda that determines which types the ConventionPack applies to. When it comes time to AutoMap a class, all the matching ConventionPacks from the registry are combined to produce an effective ConventionPack for that class. The effective ConventionPack may include multiple conventions for the same thing (if more than one matched), but the last one added is the last one to run and wins.

If you wish to write your own custom conventions, you would implement one or more of the convention interfaces: IClassMapConvention, IMemberMapConvention and IPostProcessingConvention, put them in a ConventionPack and register the pack.

AutoMap runs all the IClassMapConventions first, then all the IMemberMapConventions (on whatever members were added to the class map during the first phase), and finally all IPostProcessingConventions to do any final processing of the class map.

This change has no effect on the attribute based configuration of class maps or the fluent interface used to configure class maps via code.. However, it will be backwards breaking for 2 groups of people.
1) Those who wrote a custom convention. They will need to change their convention to match the new api, which should be relatively trivial.
2) Those who have registered a custom convention. They will need to register their convention in a slightly different manner, which is also relatively trivial.