[eliasmacpherson]

> You design (or choose) the new type such that it actually is compatible with the old type.

Yes I agree, in that case sure, but when refactoring the case can arise that a new type must no longer compatible with the old type, then auto becomes a hindrance.

std::vector and std::list have different behaviour regarding the validity of iterators after deletion (EDIT: and insertion so it seems!), to pick an example.

Maybe I'm just paranoid?

[fluoridation]

>the case can arise that a new type must no longer compatible with the old type

Then you make sure that whatever causes an incompatibility also causes a compilation error. You can't rely on text searches and IDEs for something like that.

>std::vector and std::list have different behaviour regarding the validity of iterators after deletion

Fair enough, perhaps not the best-chosen example. I was thinking about them purely as collections, rather than as part of resource management. Checking their behavior with automated tools becomes much more difficult once people start taking pointers into elements. But then again, that's true of any class. If, for example, a member function returns a reference to a member and someone gets its address, now that location is implicitly relying on the internal stability of the class in a way that's invisible to the type system.

[eliasmacpherson]

I think the example is perfectly apt, and I would not know where to start wrapping a std::list/std::vector implementation to pick up on runtime iterator invalidation.