Comment 4 for bug 1904722

Sure, it's true that on SBCL composite streams don't hold onto OS resources that need releasing. But that's orthogonal to whether programs ought to close them.

That composite streams are pure Lisp streams on SBCL is an implementation detail, not part of their standardized interface. For example, what if another implementation, or a future version of SBCL, does a broadcast stream as a wrapper around as a pipe, the other end of which is handled by a different thread? Or as a wrapper around a handle to a foreign structure created and manipulated only through an FFI? Given the permissible variations of implementation strategies, a program that doesn't close its composite streams isn't portable.

Further, 21.1.4 says that closing a component of a composite stream while the stream is open has undefined consequences. So a program that doen't close its composite streams but does eventually close underlying component streams is not conforming.

Not all programs need to be conforming or portable, but IMO SBCL ought to support programs that try to be. Conforming or portable programs are supposed to close streams when they're done using them, and so closing streams ought to behave as standardized.