The underlying problem is many VFS implementations call [chan create {read write}] without regard to the mode argument to [open].  The I/O channel subsystem is doing the right thing with the information it's being given.

What can be done?  As much as I'd like to say that we should fix the Tcllib VFSes to be good examples, this is impossible because they hide the [chan create] call within commands like [tcl::chan::memchan] and [tcl::chan::variable] which doesn't accept mode arguments anyway.

If we want to address this, I think we'd need a magic communication tunnel from the VFS [open] to the refchan [initialize] to avoid trusting the user code in the middle to pass the right mode to [chan create].  This seems fragile and distasteful to me, but what else can be done?

Maybe we say it's good enough that we fixed the one identified case of an inadvertent write happening on what was supposed to be a read-only channel, and just abandon the users to their fate should they explicitly set an output EOF character on a read-only channel that was secretly writable due to the custom VFS passing the wrong mode to [chan create].

I made another test program that cycles through many combinations of modes and operations, logging everything along the way.  Maybe it'll be helpful for studying the operation of VFS and refchan in general.