buildGoModule does support pname, so you may skip setting the name all together.

Please add a description of what modAttrs is to help other people reading the expression.

This part of the interface is the part I think could be improved. As is, it's a set of attributes to add to the mkDerviation call. Something closer to .override and .overrideAttrs would make it more consistent with the rest of nixpkgs.

The naive way to do this is to pass those two functions as attributes, and then apply them to go-modules like so:

{
# ...
, modOverrides ? {}
, modAttrOverrides ? attrs: {}
}:
# ...
let go-modules' = (go-modules.override modOverrides).overrideAttrs modAttrOverrides;
in ...

But maybe there's a cleaner way where the go-modules are an optional attribute to the main builder.

let defaultBuildGoModules = attrs:  buildGoModules {
    inherit (attrs) src sourceRoot;
    sha256 = attrs.modSha256;
  };
in
{
# ...
go-modules ? defaultBuildGoModules attrs
}@attrs:

in which case the caller can use

let
  src = fetchFromGitHub {};
  sourceRoot = "source/v2";
in
  buildGoModule {
    inherit src sourceRoot;
    go-modules = buildGoModules { 
      inherit src sourceRoot;
      sha256 = "...";
      postBuild = "...";
    };
}

Since there's a space to put postBuild in the buildGoModules call, .override and .overrideAttrs aren't required. Since the call is explicit, they're still available if necessary.

The other direction to go, is to assert that the modules build step should be kept simple, and instead only offer an extra modPostBuild attribute, a bit like fetchurl only offering a postFetch hook.

Do any of these seem like better options to you?

I prefer modAttrs to be honest. Although allowing the users to provide their own go-modules derivation is quite powerful, it does add unnecessary complexity to a fairly simple build process.