I think the main point there was that unless you check 'promises' given to you from other APIs and applications you can't rely on them conforming to the spec.

I think the main point there was that unless you check 'promises' given to you from other APIs and applications you can't rely on them conforming to the spec. As authors of Promises/A-consuming libraries, we would like to assume ... that something that is "thenable" actually behaves as a Promises/A promise, with all the power that entails. If you can make this assumption, you can write very extensive libraries that are entirely agnostic to the implementation of the promises they accept! Whether they be from Q, when.js, or even WinJS, you can use the simple composition rules of the Promises/A spec to build on promise behavior... Unfortunately, libraries like jQuery break this. This necessitates ugly hacks to detect the presence of objects masquerading as promises, and who call themselves in their API documentation promises, but aren't really Promises/A promises. If the consumers of your API start trying to pass you jQuery promises, you have two choices: fail in mysterious and hard-to-decipher ways when your compositional techniques fail, or fail up-front and block them from using your library entirely. This sucks.