I'm still struggling with the 'why' of this - why first mount a device to then disable writing to it? It just seems confusing to me. The mechanism in PC-BASIC to regulate access to devices is though the --mount option (and device options like --lpt1) and this introduces a separate and partly conflicting mechanism.

Do you have an example of how this would be used? In #186 you mention running external programs that are not vetted, though we also agreed that this should not be seen as a security feature. One could equally run such a program with no mounts, and it would have largely the same effect, though it would also block reading data files. The program itself could be loaded from a filesystem location with --load, without requiring a mount.

I think there is an issue in PC-BASIC with being able to override defaults for list options: right now it seems not possible to override the config to have no mounts. But I think the right thing to do would be to fix that, not work around it with an additional option.

There may also be a case for having the possibility of read-only mounts, though I'd also suggest you can just mount to a work directory only and copy stuff over there, so that overwrites won't cause a problem. Having an additional command-line option and a new parameter for the session seems very heavy-handed for the purpose... Particularly as one of my priorities has been to reduce the number of API parameters and command-line options; once an option is there and people start using it it becomes quite tedious to manage any change to it.

I'd have some other observations - the change to the Session API seems not backward compatible, it's confusing to open a session with an explicit mount to some device and then not be able to write because you didn't also enable writes to that device - but I think this is secondary to the more fundamental point of having two competing mechanisms to regulate device access.

As an aside, I'd also like to avoid touching the serial port implementation at all as the test coverage is poor, I don't have a serial port setup to try it, it's hell to debug because there are too many moving parts to a serial connection, and there are some people around who really depend on it working.

I think the right approach here is to start with the most fundamental question first, which is if you see any point in adding read-only mounts in some shape. Personally, I like the idea of being able to let PC-BASIC work with whatever is available on my system, as long as I know it can't make changes or communicate out what it reads. But it doesn't matter what I like, what matters is what point you see in it, if any.
I'm blissfully unaware of all the communication you've had about PC-BASIC's use with its userbase, and I also don't know what development path you see for it. Because of that, I can just make a change like this based on my personal preferences (the fact I enjoy coding also helps) and throw it at the wall. It is very much up to you to decide what sticks, and I will accept any decision you make about that up-front.
If you can see a "why" that does make sense, then your ideas about it and the future of PC-BASIC would then direct the "what" and the "how" in a rather straightforward manner. The current implementation is the one with the most straightforward configuration (from an implementation perspective) that is the least invasive one from a regular user's perspective. And it's not by accident that I chose the "lazy" approach concerning configuration, after you've already expressed your doubts in #186.

Some specific comments in response to your remark:

• In Add possibility to disable writes to disks/devices #186 I stated that I would not attach any security guarantees to this capability, and I stand by that. However, I do think a "read-only, unless" approach is a sensible thing to do in general, and disabling writes is a way to decrease the potential impact of using PC-BASIC, if it works as intended. It's the latter thing I would not want to make definitive claims about.
• If you don't want to touch the serial implementation then we'll have to take that as a premise. I don't quite see how I, or anybody, could navigate around that. Personally, I would like to try some things with serial data only coming in, but again that's just me.

Just to be clear: if you decide to not merge this and possibly never implement anything read-only then I won't be offended in any way. Nobody asked me to do this, and I enjoyed implementing it as a thing in itself. If nothing else, I now understand the workings of the I/O part of PC-BASIC a lot better than I did before.
I will use this change myself regardless, but it can also just live in my fork; it surely won't do much damage there.

That's fair, and I much appreciate your contributions and active interaction with this codebase, it's just that this feature goes against my intuitions of how the code should develop. I realise that since I don't have a public roadmap there's no way for people to know that, and my ideas may not be fully developed in the first place.

I added some observations on the kind of things I would want to work through if I were going to consider merging the PR, but what I want to avoid is having a lot of iterative updates to this PR based on my detailed feedback - only for me to then turn around and say, actually, I didn't like the concept of a 'no writes' switch to start with so tough luck.

As to security guarantees, I think we just have different views here. My sense is this is something like making people pay for parking in an enclosed area with a guard and then putting up a small sign that you take no liability for thefts. It doesn't work, as everything else gave the impression that you were guarding their car. The same admittedly applies to a read-only mount.

That's fair, and I much appreciate your contributions and active interaction with this codebase,

You're welcome, it really is my pleasure.

it's just that this feature goes against my intuitions of how the code should develop.

Then I think this PR should end here. I've ignored my gut feeling a few times in my life, and I've regretted it every time.

Concerning the scenario you want to avoid, I understand. Concerning the security guarantees, your analogy includes exactly where my view differs. Guarantees are appropriate when you pay, but I don't believe anybody's paying for this. Guarantee-wise, people just get what they pay for. That's the simple truth even if you, or we, would do (y)our utmost to fix any problem found as soon as possible, as I'd imagine.

I'll close this PR based on this conversation. If you ever do develop plans towards developing PC-BASIC that you think I could help with, please don't hesitate to let me know.