Would be nice to have the name attribute set for fetchpatch so you can roughly tell what the patch does and differentiate the patches easier when e.g. one starts failing to apply.

The contribution guidelines even require some kind of that: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#patches

Regardless of how the patch is included, you must ensure its purpose is clear and obvious. This enables other maintainers to more easily determine when old patches are no longer required. Typically, you can improve clarity with carefully considered filenames, attribute names, and/or comments; these should explain the patch's intention. Additionally, it may sometimes be helpful to clarify how it resolves the issue. For example: "fix gcc14 build by adding missing include".

carefully considered filenames, attribute names, and/or comments; these should explain the patch's intention.

Well, I do link to the issue/PR. That gives more context than a fixed comment that might even turn out to be the wrong explanation depending on how the issue/PR evolves.
In theory one could add both, but I think an issue/PR is of higher priority as it interacts with upstream.
I see the "at a glance" benefit of inlining some text in a comment here, but I'm not sure it's worth the overhead and (admittedly rare) false positives.

Note that when it comes to the specific concern of knowing at a glance whether a jailbreak/patch can be removed, we have the means to do that automatically, a-la #384591

I think giving the patch a name will give better output on the build failure (?), which would be especially relevant for an override with multiple patches. Even the automated script can't tell you which patch should be removed, right?

Yes, I'm concerned with the build output since comparing sha1 hashes is not fun.

Sorry for the delay. Been doing lots of travelling.

Even the automated script can't tell you which patch should be removed, right?

Huh good point. It sounds easy enough to build a srcOnly for each patch by removing it, but reporting multiple successes/failures per attribute looks like it's pretty incompatible with the way the script currently works.
I'll need to simmer on that for a bit.

In the meantime, I added name attributes to each patch, basically taken from the PR titles.
I wonder if it would make sense to use the issue/PR link as the name by default, which could push us a bit away from orphaned overrides.

LGTM didn't test any builds

$ nix-build \
  -A haskellPackages.basic-sop \
  -A haskellPackages.proto-lens-arbitrary \
  -A haskellPackages.proto3-wire \
  -A haskellPackages.records-sop
/nix/store/p30lmyqpfc8zfp6pv866i37nbplbszrh-basic-sop-0.3.0
/nix/store/59gs2gmy27k1kkmxirnsclp2qqw448hv-proto-lens-arbitrary-0.1.2.14
/nix/store/fgw1gbnfjyfxn36ah1r15mplvzw4xsii-proto3-wire-1.4.3
/nix/store/knhz60m4nk46rkan4jx9qdnx82ac58i8-records-sop-0.1.1.1