Looking at the patch: https://github.com/golang/tools/pull/33/files I'm still a little confused about what you're proposing. Do you have screenshots maybe or a URL that contains a concrete example?

IIUC, you want to import "golang.org/x/tools/godoc" and pass your own input into the example_text function in pres.FuncMap() to generate markdown.

IMO, this is shoe-horning the code base to satisfy a different purpose. If you look at the code change without external context, it is very hard to reason why this is being done, which is for external code to be able to generate markdown.

While I am not against generating markdown, this seems to be the incorrect approach. One should not have to import the godoc package at all to generate markdown. I would expect there to be a button in the package page which can be clicked and a .md file gets downloaded.

The idea was to be able to have the example_text2 builtin function that would allow you more flexibility by changing the title and adding delimiters to wrap the code blocks without having to write a customized function.
For example, with golang/tools#33 I could:

• have a different title than "Example:" on my code block: {{ example_text2 $ .Name "" "Example for .Name" "" "" ""
• generate the examples in markdown using (with titles to have the links working): {{ example_text2 $ .Name "" "#### Example .Name" "" "``` go" "```"
• generate the examples in asciidoc format using (with titles to have the links working): {{ example_text2 $ .Name "" "==== Example .Name" "[source,go]\n---" "---"
• generate the example in restructuredText format using (with titles to have the links working): {{ example_text2 $ .Name " " "==== Example .Name" ".. code:: go" ""

It just sounded dumb to me to have to rewrite a big function when the change I'd need to do in the core library would be really small.
I'm not really a big fan of having to duplicate entire chunks of code from the standard libraries I use just to be able to add 2 lines in it. It seemed more logical to me to propose the changes upstream directly.

The need of godoc is there because what is generated is the go documentation of the package. It's just in another format than the ones currently available.

You can already import go/doc and get a doc.Example and format it however you like. That seems like a clearer path forward than making godoc extensible in a way that it doesn't need. I would expect a godoc2md to use go/doc this way too. Don't do it by rewriting godoc itself.