Batch syntax for consecutive same-type directives

[kdeldycke]

Describe the feature you'd like to request

When documenting a Python API with MyST and sphinx.ext.autodoc, it is common to list many directives of the same type in sequence. Today, the only working approach is {eval-rst}:

```{eval-rst}
.. autodata:: mypackage.CONSTANT_A
.. autodata:: mypackage.CONSTANT_B
.. autodata:: mypackage.CONSTANT_C
.. autodata:: mypackage.CONSTANT_D
```

Native MyST directives ({autodata}, {autoclass}, {autofunction}, etc.) cannot replace this. Autodoc directives perform internal rST nested parsing that assumes an rST parser context. When invoked as native MyST fenced blocks, the generated rST content is treated as Markdown: .. becomes … via smartquotes, and rST roles like :py:class: render as literal strings. This is tracked in #587 and #228.

So the realistic alternative to {eval-rst} today is one native fence per directive:

```{autodata} mypackage.CONSTANT_A
```

```{autodata} mypackage.CONSTANT_B
```

```{autodata} mypackage.CONSTANT_C
```

```{autodata} mypackage.CONSTANT_D
```

That is three times the lines for zero additional information. This affects any argument-only directive (no body, no options): autodata, autofunction, autodecorator, autoexception, etc.

In my project (extra-platforms), I attempted a full migration from {eval-rst} blocks to native MyST directives. The autodoc rendering was silently broken: Sphinx built without errors, but the HTML contained raw rST fragments instead of rendered API docs. I had to revert all autodoc directives back to {eval-rst} (commit). The {eval-rst} requirement means the verbosity problem is not hypothetical: it is the only working path, and it forces rST syntax inside Markdown files.

Two separate but related problems

1. Autodoc directives don't work as native MyST directives (Autoclass directive works in rST but not Markdown  #587, Allow for autodoc to parse Markdown docstrings #228). This forces {eval-rst} for all API documentation, making it impossible to write pure-MyST docs for any project using sphinx.ext.autodoc.

2. No batch syntax for consecutive same-type directives. Even if Autoclass directive works in rST but not Markdown  #587 were fixed and native {autodata} worked, listing 50 constants would still require 50 separate fenced blocks instead of a single block with 50 lines.

Scope

This would only apply to directives that:

1. Take a single required argument (the object name).
2. Have no per-invocation body content.
3. Accept identical options across all entries (or no options at all).

Directives with per-entry bodies or heterogeneous options would continue to use one fence per invocation.

Context

The original directive syntax discussion (#63) chose fenced blocks because they degrade gracefully in non-MyST renderers. That rationale holds: a multi-argument block still looks like a code block with a list of names in any Markdown viewer.

Related issues

• Autoclass directive works in rST but not Markdown  #587: autoclass directive works in rST but not Markdown (open since 2022)
• Allow for autodoc to parse Markdown docstrings #228: Allow autodoc to parse Markdown docstrings (open since 2020)
• Markdown syntax for roles and directives #63: Original Markdown syntax for roles and directives discussion

Describe the solution you'd like

Allow a fenced directive block to accept multiple arguments, one per line, when the directive type supports it:

```{autodata}
mypackage.CONSTANT_A
mypackage.CONSTANT_B
mypackage.CONSTANT_C
mypackage.CONSTANT_D
```

Each line in the body would be treated as a separate invocation of the directive with that argument. This is analogous to how {toctree} already accepts multiple entries in its body.

Options could apply uniformly to all entries:

```{autofunction}
:noindex:

mypackage.func_a
mypackage.func_b
mypackage.func_c
```

Describe alternatives you've considered

• {eval-rst} blocks: work today, but force rST syntax inside Markdown files and prevent MyST-level validation of the directive content.
• Code generation: my project generates these blocks from Python, so the verbosity is hidden from humans. Hand-maintained docs don't have that luxury.
• autosummary: solves the listing problem but changes the rendered output (summary tables instead of individual docstring blocks). Not a drop-in replacement.