This does help already, thanks.

However, the contents of the files are still very malformatted compared to what I would like (as mentioned, as close to the Microsoft documentation pages as possible). You can compare the generated file for the Module class to the one I made by hand. I'll concede I am missing some things (inherited members, extension methods).

But some parts of the generated content is different for no apparent reason:

• the arrow for inheritance (←) is the other way around,
• primitive type names aren't converted to their real names (expect nuint -> UIntPtr),
• inherited members and extension methods are comma-separated, making them very difficult to read,
• the symbol name and kind are backwards (Class Module instead of Module Class).

Some parts appear to be plain broken:

• <see cref="..."/> tags are entirely ignored it seems, leading to incorrect grammar.

And, in my opinion, the generated files are very difficult to read and navigate:

• the files do not have any kind of hierarchy (directories for the namespaces would be nice at least),
• the files contain all of their members and their information back to back, making it hard to spot anything substantial at a glance (distinguishing between an H3 and an H4 is already hard enough); I would love for them to be generated in such a way that a type only contains a table of contained members (split into fields, properties, methods, constructors, etc.) and for those members to have their own file, leading to a very easy-to-navigate file tree.

Here's an example of what I was hoping the file structure to be like:

Is there anything at all I can do to have it generated my way?

markdown output format support are recently added. (#684)
So there may be missing features for some use cases.

the arrow for inheritance (←) is the other way around,

It seems modern templates and markdown/apiPage output use UML style inheritance arrow direction.
When using default template. It use learn.microsoft.com compatible inheritance arrows.

I don't know why these style are changed at modern template.
I'll create separate Q&A discussion(#9718).

primitive type names aren't converted to their real names (expect nuint -> UIntPtr),

docfx resolve symbol name to language dependent display name by using Roslyn API (SymbolDisplay.ToDisplayParts).
Currently there is no options available to change this behaviors.

inherited members and extension methods are comma-separated, making them very difficult to read,

Currently API Page-based pages don't support template customization.
It's required to modify ApiPageMarkdownTemplate.cs markdown generator. or adding new output format.

the symbol name and kind are backwards (Class Module instead of Module Class).

As you say, page title (<h1>) name don't seem to be compatible with learn.microsoft.com API reference page.
I don't know there is historical reasons of these or not.

tags are entirely ignored it seems, leading to incorrect grammar.

it seems cref tag is rendered as <xref href="Example2.Module" data-throw-if-not-resolved="false"></xref>.
It might needs custom post processing steps to resolve outputted xrefs inside markdown files.

And, in my opinion, the generated files are very difficult to read and navigate:
the files do not have any kind of hierarchy (directories for the namespaces would be nice at least),

It can split files by specifying "memberlayout": "sepatedPages" option.
To grouping markdown files by directory.
It need to additional option something like separatedDirectoryPages.

Thanks for the info here. Separating the files helps a lot with readability. It's still a bummer that the members aren't listed in a proper (header-less) table like they are on learn.microsoft.com though.

There are some more issues I've found:

• the markdown files' headers include (what I believe to be) an attempt at an anchor (# <a id="AslHelp_Memory_Module"></a> Class Module); this does not work and instead makes the actual anchor to said header malformatted (#-class-module instead of just #class-module); an actual markdown anchor looks like this: [Class Module](#AslHelp_Memory_Module) (edit: seems like this is already reported at [Feature Request] Make <a/> tag in headers optional when outputFormat: markdown #9720),
• enum values are ordered alphabetically instead of in the order they were declared or the order of their numeric value (this is likely due to the fact that enum values are treated as fields, which are always ordered alphabetically),
• types under Property Value or Returns have a leading space; not an issue, just something I noticed,
• DocFX is incapable of generating documentation for classes in the root namespace (as in, no namespace was provided),
• I believe DocFX may be broken for record struct types, unless I'm incorrect:
  • it generates { get; init; } accessors for record types' properties,
  • it generates { get; init; } accessors for readonly record struct types' properties,
  • but it generates { readonly get; set; } for record struct types' properties; I don't believe set is correct here,
• this[T] indexers have their pages generated with the header Property this, which is misleading; the learn.microsoft.com pages use Item[T] Property as the header.

Like you mentioned, cref gets generated as xref, which cannot be displayed at least by GitHub-flavored markdown.
I haven't found a way to generate files in separate directories.

It would be nice if generated files contained a link to the original source file, ideally including a direct link to the line of the declaration (to the field, property, method, constructor, etc.).

You mention "adding a new output format". How do I do that?

As mentioned in the other answer, there is an output format named markdown that you can use. I'm personally not happy with its output and I have not been able to generate what I desire.