where in the functor payloads the information can be found

the final merged configuration isn't visible to the functor. Because it only exists after merging option definitions. Option definitions can only exist once a type is used with an option.

where in the functor payloads the information can be found

the final merged configuration isn't visible to the functor. Because it only exists after merging option definitions. Option definitions can only exist once a type is used with an option.
So if you must do this from the type's perspective, the base-configuration (pre option-merge) is all you have access to.

The functor you referred to is options.services.<module>.type.functor, right? Note that you've stepped from the option (options.services.<module>) into its type .type. The type's functor is defined when the type is created, before any options are in the picture.

The option itself has access to it's final merged value (options.services.<module>.value) and if its type supports v2 check+merge, you may also have merged metadata (options.services.<module>.valueMeta). Note how none of that is under .type.

Once you return options.services.<module>.type.getSubOptions options.services.<module>.loc you have a new set of options that came from the type's base configuration; you've lost all knowledge of the owner option, its definitions, merged value, or merged metadata.

I always recommend trying to keep the prefix accurate, so that once you have your final list of options you can do "${opt}" or showOption opt.loc and get the correct option attrpath. But you're right, functionally it makes no difference.
Having correct locs can be useful in attrsOf submodule scenarios, too, where we typically add "<name>" to the prefix. Or listOf submodule where we add "*" to the prefix.

In my interpretation of getSubOptions, it makes no guarantee of its structure. Imagine a type like either or attrTag, where different submodules could in theory be supported. It may make sense for such a type's getSubOptions to return an attrset of wrapped-type-name -> sub-options to avoid naming conflicts.

I'm not aware of any types that do that currently, but it's something to be aware of.

I always recommend trying to keep the prefix accurate, so that once you have your final list of options you can do "${opt}" or showOption opt.loc and get the correct option attrpath. But you're right, functionally it makes no difference.
Having correct locs can be useful in attrsOf submodule scenarios, too, where we typically add "<name>" to the prefix. Or listOf submodule where we add "*" to the prefix.

This may be controversial, but in my interpretation of getSubOptions, it makes no guarantee of its structure. Imagine a type like either or attrTag, where different submodules could in theory be supported. It may make sense for such a type's getSubOptions to return an attrset of wrapped-type-name -> sub-options to avoid naming conflicts.

I'm not aware of any types that do that currently, but it's something to be aware of.

Yeah. Although currently that's not very common because it's not easy to discriminate between submodule-specific module definitions. A more practical example may be

either (attrsOf submoduleA) (listOf submoduleB)

gotcha, i was foolishly hoping for a

                value = if length defs == 1 then (head defs).value else elemType.merge loc defs;

I was gonna say something similar:

Wouldn't that only buy you ~1 lambda invocation per option (the elemType.merge call)? The elemType's merge function itself should already be doing something trivial in trivial cases

I also have an optimization that I'm not totally sure about. In the case that nulls.right is nonempty (meaning that some of the values are null), you do:

  valueMeta = optionalAttrs (nulls.wrong != [ ]) checkedAndMerged.valueMeta;

But if nulls.wrong != [], then we're going to get an error. [...]
So I think we can set valueMeta = { } here, and behavior will be unchanged.

I'm also not 100% on that. valueMeta should (typically) only be evaluated when introspecting options, or extending them in non-standard ways.

IIUC, it's supposed to work even if there are (unrelated) errors.

Originally, checkedAndMerged was checking & merging nulls.wrong, so nulls were already filtered out. Meaning it was possible for code that didn't care about our mixed-null-non-null assertion to still read what the elemType would've returned for valueMeta.

If that has a large performance cost, it may not be worth it; so you're optimisation may be acceptable. Ideally we'd get @hsjobeki or @roberth's input on idiomatic valueMeta in a partial/unrelated error scenario.

Looking at how it simplifies the overall diff, I personally think it's fine.

lib.types: don't take loc parameter in checkDefsForError

I'd prefer we didn't increase the scope of my PR to include this. Do you mind moving that to a dedicated PR against nixpkgs?