We have a convention that we mostly follow. Adding new stuff with variations in the convention offers no benefit without also adjusting the rest of the API. Inconsistencies really do not assist any developer.
Where APIs have been added that don't follow the conventions they should be changed. It really is that simple - each developer may have a different set of personal preferences and if we simply allow any two people to pick their own API pattern effectively at whim we end up with a real mess over time. This example is a clear cut case where we should fix the unnecessary variation in the pattern. It serves no benefit whatsoever to have such a mix of API patterns. We do have some variations that we should adjust - and for APIs that have been in official releases dropping in backwards compatibility macros is appropriate. The argument that we aren't completely consistent is specious - it is saying because we have a few mistakes that have slipped through the cracks we have open season on API patterns. It also would not hurt to have an automated check of API deviations on commits to catch such things in future. Tim.