Actually something like --read-only=warn but without the warnings...

This might sound like an oxymoron but it's not.  After all, you can 'vi' a file which is read-only and as long as you're the owner (or super-user), use 'w!' to rewrite it.

The idea is to provide a similar capability to 'patch', possibly via an optional flag which enables this normally suppressed capability.

The issue is that sometimes you run an automated build machinery (like 'buildroot') which downloads tarballs and patches them as part of the build process.  Occasionally the authors of these tarballs bundle them as 0444 assuming that they are perfect as is and no one needs to patch them.

Well, in a perfect world...

But in some corner cases (often involving old compilers, ancient versions of autotools, or out-of-the-mainstream runtimes like uClibc or MUSL), things fail to build and need to be patched.

Not the end of the world.

So how to patch them?

Either patch needs to be able to save the original perm, chmod u+w the sources, change them, and then chmod them back to the original permissions... or else something uglier with more potential consequences needs to happen.

You could 'grep' out of your patch file all the file names which need to be changed, and for files which exist but don't have owner write permission, change that... That works fine for compiled sources, but has potential unintended consequences for script files which get install'd without any -m xxx flag (i.e. assuming that the original permissions haven't been modified and that they should be preserved across the copy into $DESTDIR...).

Not reliably always the case either.

So the best bet is to save the original perms, chmod them up temporarily to u+w, modify the file, and then chmod them back to the original modes.

This has no unintended consequences.