No, it does not collide with "canonical" (colloquial, I'd say) definition of streams, when you think about it. It's only a matter of guarantees on a stream. It is not buffered reads/writes that make a stream.

I can take a bunch of XMLs, "stream" them into a TCP socket on one end, feed that socket to "XML stream processing library" on another end and... Watch it blow up, because apparently the only streamy thing about the library is that it can handle asynchronously filled buffer, but will nevertheless blow up if fed anything but a single well-formed xml ¯\_(ツ)_/¯

It is not colloquial when talking about network protocols. From socket(2):

          SOCK_STREAM
              Provides sequenced, reliable, two-way, connection-based
              byte streams.  An out-of-band data transmission mechanism
              may be supported.

Not sure what your reference to buffering or async buffers and XML has to do with the topic.

Here you go, right in the documentation you get that TCP streams are streams with additional qualifiers. Not simply streams. The whole thing we are arguing about: TCP streams are subset of streams.

> Not sure what your reference to buffering or async buffers and XML has to do with the topic. An illustrative point for what happens when assumptions from a contrived case are applied on a more relaxed case.