The point of having a COM interface is to take versioning out of the equation - if you're actually altering the interface, the usual practice is to add an additional interface to the same object. For example IFoo extends another interface IFoo2 with the first change, IFoo3 with the next change, etc.
In short, if the behavior of the interface changes, then it really should be a new interface. The same logic applies for changes that would break an existing interface. For example, if you have something like...
IFoo.Bar(baz as string)
...and the implementation changes, you would create a new method, using a new interface that extends the old one with that method - i.e.:
public interface IFoo2 : IFoo
{
void Bar2(string baz);
}
Then document in your change notes that callers should use the newer interface because of the extended functionality. Microsoft did something similar with the *Ex methods in the Windows API, and IIR did the same thing with some of the objects in MS Office.
An alternative is to update your unit tests to account for new calling conventions (assuming that acceptable parameter ranges are changing but the return values aren't changing), and then code to the unit tests. In this scenario, the interface itself wouldn't be changing as long as it still produces the same behavior with the original range of inputs.
