I believe that the delete/append ports of the file device really should
be changed, and then their current function is only if #01 is written.
However, it is unclear what should happen if a value that the emulator
does not know, is written. (One possibility is to close it, and to refuse
to open again until zero is written later to reset it; this seems to
me the least likely way to confuse programs.) Unfortunately, existing
emulators will need changed.

I think that seeking and a few other things are helpful, although it
probably does not need to be complicated with locking, etc. (Therefore,
I had deliberately omitted locking and other things like that, only
adding a few simple things that nevertheless seems important. It is a
bit complicated, but file dealing might need to.)

I have implemented the below in Uxn38 (currently, only if the -x switch
is specified), and have copied the relevant part of the documentation in
this message. You can make a comment of it, and suggest if changes should
be made, please.

=== begin ===

The delete port can be given any of the values:

* 0x00 = Does nothing.

* 0x01 = Delete the current file. (Not currently implemented.)

* 0x10 = Close the file.

* 0x11 = Open the file for reading. Success is 1 if opened.

* 0x12 = Open the file for writing. Success is 1 if opened.

* 0x80 to 0x8F = Seek. Bit0 and bit1 specify how much the length field
should be multiplied by, where 0 means zero, 1 means one, 2 means 64K,
and 3 is reserved. Bit2 and bit3 indicate where to seek and which way,
where 0 means forward from the current position, 1 means backward from
the current position, 2 means forward from the beginning, and 3 means
backward from the end.

Telling it to open a file will close it first, even if it is already open
in the correct mode. Also, seeking will not work unless the file is already
open, so it must first be opened, either by one of the above commands for
opening a file or by attempting to read from or write to it.

The append port has one of the following values:

* 0 = Files opened for writing are truncated.

* 1 = Files opened for writing will append at the end of the file.

* 2 = Files are opened for both reading and writing. In this case,
switching from reading to writing or vice-versa will not close and reopen
the file like it does in other cases. If writing is disabled, then this is
treated the same as 0.

Any value may be bitwise ORed by sixteen to refuse to open a file for
writing if the file already exists.

=== end ===

The file vector should be reserved for communication uses (which most
emulators probably can ignore).

-- 
Don't laugh at the moon when it is day time in France.

I just wanted to say that I've see and read this, and the only reason
I haven't gotten back to you yet on this is that I need to try it out
for myself. So stay tuned, as soon as I can I will experiment with
your fork of the file device.