If multiple proprietary software packages are talking to each other at all, there must be either an implicit or explicit specification they're talking over. And if that interaction is broken, that implies that either (1) the spec is ambiguous/wrong or (2) one or both parties are implementing the spec wrongly.Yes. Aerospace takes that seriously. So does the military. That's why Rolls-Royce engines can be taken off a B-787 and replaced with GE engines. The software industry rarely takes interoperability seriously enough to make such things work.
Many years ago, at the dawn of the TCP/IP era, I worked for a large aerospace company. We had a pre-Berkeley TCP/IP implementation from 3COM, originally intended only to talk to itself over Ethernet I brought it up to compatibility with the spec, and added a logging mechanism which logged every packet which was either wrong or which did not advance the connection.
Every day, I read through this bit bucket, and wrote emails along the lines of "Your TCP implementation is not compliant with para. xxx subparagraph yyy of the standard. See this dump of packet zzz where value aaa is incorrect due to bbb." After a while, interoperability improved.
We could do this was because, as a large aerospace company, we were bigger than the networking companies we bought from. So we could pound them into complying with the published spec. We also had backing from DoD in this; they wanted interoperability. Back then, many vendors didn't; they wanted their own dialect of networking. This was the era of SNA (IBM), DECnet (DEC), ARCnet (Wang),
and a whole bunch of incompatible PC-oriented LAN systems. Mixed-vendor shops were unpopular with the old-line computer makers. The idea of everything talking to everything else, and it all just working, was new then. It took a lot of effort on the buyer side to make that happen.