I���d even propose to have it by default: a FileReference writeStream can return a ZnNewLineWriterStream wrapping the corresponding stream.
By default it can be configured with the system���s default line ending convention (least surprise?).
And then users can change it accordingly���

Now I ask also myself what we could do when reading line endings from a file.
I���m 98.761% convinced that in the image we should have a single line ending convention for strings, and that we should convert internal strings to the external representation of convenience explicitly.
In this direction we could make that default read streams in FileSystem to automatically transform external line endings into internal line endings.

Maybe, maybe.

It would still create the assumption that the standard stream has lots of functionality that you can automatically count on. Then it feels that we are back to where we started.

The goal was to simplify, with simple, compose-able functionality.

I know that the implementation would still be more or less modular, but many layers also carry a performance price.

I feel like I am fighting a losing battle trying to simplify and clean up the stream API.

The fact that we cannot use Traits is another problem, because inheritance does not cut it. See the old NILE project.