Naming conventions for replacement APIs / classes

Do you have a naming convention for APIs or Classes that are being phased in to replace an older version that performed the same function / filled the same role?

E.g. Windows does this by adding "Ex" to the end of the function:

ShellExecute // old
ShellExecuteEx // new

What do you prefer, and what are you reasonings?

• Appending 2, V2, New, NowInStereo?
• Doing a one-time rename of the old API from Something to SomethingOld and using Something for the new stuff? This option worries me when it comes to version control, but it also seems the least likely to be burdened with a V3 or ReallyNew problem in the future.
• Making up a completely different name that may describe the function less accurately, but at least is different.

From stackoverflow

• Why change it at all? Interfaces being the contracts that they are, why would you break the interface after everything is using it.

  Edit: Sorry to botch your comment Josh...

  I think that if you've gone to the trouble to create the interface you need to do everything you can to maintain it. What kind of bad choice were you thinking about when you commented before?

• If the new class performs the same function as the old one, I remove the old one and replace it with the new one with same name. I can still consult the old one in version control if needed.

• Much of the time you can get away with changing the package name, rather than the class name itself.