I can look into fixing this as a follow-up based on native.module_name.

Unfortunately, native.module_name can only be used in the loading phase :/

My idea was to add a module_name parameter to the stardoc macro that uses native.module_name as the default.

On further reflection, I think the right place to fix this should be in starlark_doc_extract - we want to be able to optionally provide the local repo name for all labels (including e.g. label attribute defaults), in the proto output as well as in markdown.

The starlark macro can then provide the local repo map (obtained from native.module_name or a manual override for cases where the recommended repo name for a module's users is different from the module name) to the starlark_doc_extract target.

When you say "local repo name", which name are you referring to exactly? The apparent name used by the root module?

What would comprise the "local repo map" that you would want to have passed into the rule?

By "local repo", I mean the repo of the stardoc (and starlark_doc_extract) target.

Currently, starlark_doc_extract treats that repo as if it were the main repo for the purpose of stringifying labels in proto output. This behavior made sense to me at the time when I implemented it because it meant starlark_doc_extract's output is the same regardless of whether doc targets are being built in their own repo or by a user of the repo, and thus made golden tests sane/predictable.

In retrospect, the correct behavior should have been to allow the name of the local repo to be remapped to a custom one when stringifying labels.

I submitted bazelbuild/bazel#19002, please let me know whether this is what you had in mind.