When do we break binary compatibility

I was under the impression that whenever you do one of these:

• Add a new public virtual method virtual void aMethod();
• Add a new public non-virtual method void aMethod();
• Implement a public pure-virtual method from an interface virtual void aMethod override;

Was actually breaking binary compatibility, meaning that if a project had build on a previous version of the DLL, it would not be able to load it now that there is new methods available.

From what I have tested using Visual Studio 2012, none of these break anything. Dependency Walker reports no error and my test application was calling the appropriate method.

DLL:

class EXPORT_LIB MyClass {
public:
  void saySomething();
}

Executable:

int _tmain(int argc, _TCHAR* argv[])
{
  MyClass wTest;
  wTest.saySomething();
  retu 0;
}

The only undefined behavior I found was if MyClass was implementing an pure-virtual interface and from my executable, I was calling one of the pure-virtual method and then I added a new pure-virtual method before the one used by my executable. In this case, Dependency Walker did not report any error but at runtime, it was actually calling the wrong method.

class IMyInterface {
public:
  virtual void foo();
}

In the executable

IMyInterface* wTest = new MyClass();
wTest->foo();

Then I change the interface without rebuilding my executable

class IMyInterface {
public:
  virtual void bar();
  virtual void foo();
}

It is now quietly calling bar() instead of foo().

Is it safe to do all of my three assumptions?