Agreed, essential for efficient logging of most types (you could in theory rename and copy the old file first, but...
That doesn't work if two processes are appending at the same time (which is guaranteed to work with O_APPEND).
Essential for e.g. databases unless you can direct your ports to not buffer inside the Scheme implementation. See below.
Also essential for a simple random-access fixed-length-record file.
Although, what about databases where multiple processes access a file?
Exercise great caution, or write using a server behind a socket or named pipe, or use those *@#$* broken Posix locks.
None of these strike me as "essential", but all are nice to have. If on top of a POSIX system, not much extra work if you include append, but what about Windows??
Windows has all these flags and more.
f) buffer (size of buffer if any)
An efficiency thing, modulo the above mentioned option to set it to zero size.
The intended available sizes are zero, a single line, a fixed size, or a default size.
k) posix-permissions (when a file is created, what permissions to use; this is _not_ equivalent to creating with one set of permissions and then changing them).
How essential for security??
If you open a new file with a mode that forbids writing, you can still write on it, but nobody else can.
Obviously absolutely essential to create files with holes, which is essential for restoring files in POSIX systems. Which as I previously commented are less rare than one might think.
Also for the fixed-size random accessed record files I mentioned above.
Cygwin goes to a lot of trouble to let process select() on both sockets and files. On reflection, though, this will be needed for processes too, so it may need to be a separate SRFI.
I have a new idea, though:
Provide an open-file procedure, which accepts a pathname and the following keys: append, create, truncate, exclusive, buffer, and posix-permissions, and then returns a fd, which you can then transform into a port with the SRFI-170 fdes->port procedures. This only requires a simple FFI.
The other keys, namely bidirectional, char-buffer, encoding, newline, and encoding-error, are relevant only to textual ports, so they would only make sense on open-input-file, open-output-file, fdes->textual-input-port, and fdes->textual-output-port. This is logically part of SRFI 170, but until we know whether keywords are in or out, we can't integrate it satisfactorily. What's more, it involves deeper integration with the implementation's ports than anything in SRFI 170. So keep it separate for the present.
Contra what you said, it's not having a minimal number of non-portable SRFIs that matters. Splitting a SRFI up doesn't make things harder, it may even make them easier.