You are not logged in

Really, the only thing patch can tell you is if a patch can be reverse applied. From that you may want to assume that the patch was already applied, but there is no guarantee: there are cases where the same patch can be reverse as well as forward applied. There is no such thing as idempotent patching as long as the patch doesn't contain both files in their entirety (i.e., with infinite context).

Consider the following, I'm building a specific software for all released versions. Since version 3 and on a specific feature was added.

If now one wants to build all software versions (also 1 and 2) with that features, applying the patch to them would work out. For version 1 and 2 it would apply cleanly, but for 3 and on it would be ignored as it was already applied.

"already applied" is a very different outcome in this case than "patch didn't cleanly apply".

The description of the --forward option in the man page isn't very clear. Here is a better version:

When a patch does not apply, patch usually checks if the patch
looks like it has been reversed. The --forward option prevents
that.

Patch doesn't ignore (or "silently apply") patches like three-way merge usually does. The result wouldn't be reliable enough with the information available. If you insist on ignoring patches that look like they have already been applied, do so by checking if they can be reverse applied.

If I read the manual page correctly, '-s --forward' should silently apply a forward patch, and just drop it if applied already. It does this, but prints a warning and returns non-zero, which is not what one wants when writing shell scripts.

I am not sure what you mean. A patch that has already been applied can be reverse applied, which reverts it. (This may fail if the patch modifies the same file more than once though.)

Also note that patch uses a heuristic to determine if a patch has already been applied, and that this heuristic can fail. Trying to revert the patch with --reverse --dry-run is safer. This can also fail if a patch file modifies the same file more than once though.

Software projects building their own patched kernel are often the source of kernel fixes. This patches will appear in the project tree and be submitted upstream, eventually appearing in kernel releases.

This creates scenarios where a patch might be attempted on a kernel release that's already been applied.