In D13361#278943, @kib wrote:

For instance, we do not guess the filesystem type in the kernel. Why rw/ro should be different ?

Because it's convenient and it is really not hard or messy to implement.

Another, perhaps weak, argument is that mount(8) does not mandate behavior for the case where neither ro or rw are requested (the default is not documented) and that leaves room for the proposed change.

In D13361#278954, @avg wrote:

In D13361#278943, @kib wrote:

For instance, we do not guess the filesystem type in the kernel. Why rw/ro should be different ?

Because it's convenient and it is really not hard or messy to implement.

Another, perhaps weak, argument is that mount(8) does not mandate behavior for the case where neither ro or rw are requested (the default is not documented) and that leaves room for the proposed change.

Historic unix behavior is against you. People rely on the current behavior failing when the disk isn't writable to keep them from proceeding in, for example, their scripts. They don't specify rw because that's the default and has been the default behavior since Bell Labs First Edition Unix when the mount command was introduced...

I'd rather focus on the convenience of a modern user than on the historic Unix behavior.

Not sure if any of you use a FreeBSD-based desktop environment, I do, KDE.
It's supposed to be one with the most knobs.
Unfortunately, it does not offer a read-only mount button, just mount.
So, if I happen to insert a write-protected SD card, then I cannot mount it through the desktop interface.
Of course, I know how to use the command line. And, of course, it's a deficiency of KDE that it does not offer a readonly mount option and does not automatically detect readonly media, etc.
But if I can make things a little bit better (for myself, first and foremost), I try to do it.

P.S.
And it's a shame that we have VFS / buffer cache bugs like this one https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037#c0 and they do not get fixed for many months (if not years).

In D13361#278967, @avg wrote:

I'd rather focus on the convenience of a modern user than on the historic Unix behavior.

I'd rather not break scripts that reply on this behavior. I know of several that exist at prior employers.

It's not a no, but it's push back that this isn't POLA based on what people expect.

And it's a shame that we have VFS / buffer cache bugs like this one https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037#c0 and they do not get fixed for many months (if not years).

We all know there's issues in the buffer cache for a long time. This is but one of many problems there, and it isn't so easy to fix. Every time I've tweaked code in that area, I've discovered I introduced another bug that's not discovered or traced down for months... It's also orthogonal to the current issue at hand... Then again, I've been looking to fund a position that would do nothing but fix the strange panics from the error path of the buffer cache/ufs w/o luck. :(

It's not a no, but it's push back that this isn't POLA based on what people expect.

Well, it depends on definition of "people".
I know that one wide-spread OS does this and so some people are used to it.
"mount: block device /dev/sdb1 is write-protected, mounting read-only"
But I am not sure if it does that in kernel or in userland.

In D13361#278984, @avg wrote:

It's not a no, but it's push back that this isn't POLA based on what people expect.

Well, it depends on definition of "people".
I know that one wide-spread OS does this and so some people are used to it.
"mount: block device /dev/sdb1 is write-protected, mounting read-only"
But I am not sure if it does that in kernel or in userland.

I might accept this behavior if enabled by a specific mount option. But generally this is quite anti-pattern for Unix, where command does exactly what asked for or fails.