You should be able to access it through the ZManaged companion object, I think

I can't access it like you mention.

Oh right. We need to modify the ZManaged companion object to extend the ZManagedPlatformSpecific trait.

Let's move this to its own file. It can also be public.

Same- separate file and public.

This can become a constructor for ZInputStream:

object ZInputStream {
  def fromInputStream: ZInputStream = 
    new ZInputStream {
      // implementations
    }
}

Same as InputStream - this can become a constructor of ZOutputStream.

The chunk size here should be configurable

With this signature, there's no way for the caller to infer if the input stream is exhausted. How about encoding this as ZIO[Blocking, Option[IOException], Chunk[Byte]], where Some(IOException) is an actual error, None is an end-of-stream signal and a value is a chunk?

I would also suggest to make the non-blocking read optional (using a flag). If the flag is false, don't check available before reading and just let the underlying input stream manage that.

Great suggestion. I think we should remove the available check alltogether if we use the encoding you proposed. And have each implementation decide how it wants to deal with readN on an exhausted stream. I think it makes things simpler.

What do you think?

This can be ZIO[Blocking, IOException, Chunk[Byte]] and the blocking can be configured through a flag.

I understand. Looking at ZIO[Blocking, Option[IOException], Chunk[Byte]] from readN I think this place would be a good one to use the same encoding and also drop the available check alltogether (we already get the info from the read return code).

Should we always flush?

Good point. No, we don't. I was thinking about treating write + flush as "atomic" in a write, but it doesn't have to be and it would actually reduce performance (because of all that IO). I will remove the flush.