I don't confuse these. This distinction is precisely the point of the article. You can test external APIs and contracts. You can't test internal versions. You can design systems to be 100% testable via their external contracts. A system implements N such contracts. This list is a solid basis for "what is this software" whereas a single internal version number is not.
The question is what happens when you release a product that supports API/contract version 3.2.6 and passes all tests, but then later a bug was found in its implementation of API/contract version 2.3.6 which did not get discovered by testing?
Manufacturers of products that have to perform to some standard will put serial numbers on their products and then may issue a recall based upon the serial number; presumably something analogous should be issued where we currently use a version number (e.g. a build ID or git revision).
