Was this change in behavior intentional?

Definitely not. Which VFS are you experiencing this with?

Edit: i can now reproduce this with one out of three tested VFSes, so will assume you're using that one. The root of the problem is not immediately obvious but is under investigation.

Since 3.46.1, trying to perform a mutation causes all subsequent queries on that connection to fail with the error SQLITE_IOERR_WRITE: sqlite3 result code 778: disk I/O error, so you have no choice but to make a new connection.

That's now fixed in the trunk and the 3.46 branch, so will be part of 3.47 and any hypothetical future 3.46 releases. Thank you very much for the report!

This problem actually dates back to the initial release of this VFS. It's possible (i've not confirmed) that it misbehaved differently in versions before 3.46 (perhaps even by hiding that misbehavior), but it was definitely not properly honoring the mode=ro flag. Tests have been added to ensure that mode=ro is honored and that the VFS behaves properly on following read-only operations after a failed-due-to-read-only error.

Awesome! Thanks for looking into this.