Why isn't "the collection of input parameters to this function" a concept in my program? I understand it's applicable scope is smaller than a e.g. DTO, but does that matter categorically?

I suppose it could be, but imo it starts diluting the value of domain modeling if everything is given the same weight. A bundle of inputs to a function just doesn't have the same weight as a struct representing a repository or a commit or something, so modeling them as the same concept just doesn't sit right with me. It could be a personal thing, though.

> A bundle of inputs to a function just doesn't have the same weight as a struct representing a repository or a commit or something

That's true. But IMO a language primitive can carry a wide variety of semantics.

> it should represent a concept that makes sense outside of the context of passing it to one function in particular

Why? What's the utility? Fewer characters?

Because concepts in programming languages mean things. A discrete, named entity (a struct) is a distinct concept from a way to increase readability of a function call (keyword arguments). Overloading them with the same language construct is compressing disparate concepts. It's the same thing when "Go has no set type" comes up and people say "map[T]struct{}!" You might implement a set using a map, but they're fundamentally different concepts

> Because concepts in programming languages mean things

Right, but a struct means "a collection of named parameters", not "a concept in your domain model" although a struct can be used to model the latter.

> A discrete, named entity (a struct)

Structs don't have to be named. E.g., `var person struct { Name string; Age int }`.

> It's the same thing when "Go has no set type" comes up and people say "map[T]struct{}!" You might implement a set using a map, but they're fundamentally different concepts

It's not the same thing at all. In your analogy, a map is not a set but the advice says to use the map instead of the set anyway. But we're not talking about using one thing as another, we're talking about using a struct as a struct--one such (common) use for a struct is passing named values into a function.

> A discrete, named entity (a struct) is a distinct concept from a way to increase readability of a function call (keyword arguments).

If you take

    func NewServer(addr string, certKey, certCA []byte, ...) (*Server, error)

and coalesce the input parameters into

    type ServerConfig struct {
        Addr    string
        CertKey []byte
        CertCA  []byte
        ...

then that type is still a meaningful domain concept in your program. There is no minimum scope requirement for discrete, named entities, is there?