Thanks @zoziha. Though potentially useful (other than for fixing the logger), I'm not convinced that these are necessary.

A downside is that it complicates the API--we're now adding the 4th (Fortran-specific) letter to the syntax. It's a development and maintenance cost for us, and a learning cost for the user.

The upside is that it'd now work with the stdlib logger, and users who want to use sequential or direct access with stdlib_io open, now can.

I wonder if we should deprecate sequential and direct access from the stdlib_io POV. Is there anything that we can do with sequential or direct access that we can't do with stream access? If yes, the solution to #465 would be to update the logger to use stream access.

My feeling is similar to @milancurcic in that the beauty of the open function is that it behaves similarly to Python or C and it simplifies the usage. The letters / API that it allows are cross platform, there is nothing Fortran or C or Python specific in it and most people quickly understand the usage. This PR adds some Fortran specific usage, and to be honest I myself would not be able to explain the difference between "u", "d" and "s", without studying. It seems it's not worth doing --- if a specific application demands this level of control, then using the intrinsic open statement seems like the way to go.

Okay, I think what you said is correct and reasonable. It seems that we should try to modify the sequential requirements in stdlib_logger to stream. (see #465 )

FWIW I agree with @milancurcic and @certik regarding the additional letters in open().

I think we discussed with @wclodius2 the differences between sequential vs stream for stdlib_logger when he developed it. But I can't find back this discussion. So I may be wrong. I highly suggest to discuss this "issue" with @wclodius2 before opening a PR.

I am on travel again. Travel and catching up on activities delayed by travel, makes it hard to code and document the code. Right now my coding is focussed on hash functions and hash tables. I had thought I was caught up with the coding for hashes, but SMHasher added some more tests (particularly for bad seeds), that showed problems with some of the hash codes I had adapted, and added some hash codes that were better than what I was using, so I have been redoing my hash codes. When I get these into stdlib I will be willing to go back and redo some earlier codes.

I am on travel again. Travel and catching up on activities delayed by travel, makes it hard to code and document the code. Right now my coding is focussed on hash functions and hash tables. I had thought I was caught up with the coding for hashes, but SMHasher added some more tests (particularly for bad seeds), that showed problems with some of the hash codes I had adapted, and added some hash codes that were better than what I was using, so I have been redoing my hash codes. When I get these into stdlib I will be willing to go back and redo some earlier codes.

@wclodius2 Nice that you are working on the hash codes. If you need some help, don't hesitate to ask for it.
Re: stdlib_logger, we will first see what will result from the future discussion ;)

Thank you for your comments. It seems that this PR is unnecessary, and I will cancel this PR.