nixos-render-docs: Parsing error when nesting blocks without ::::

[nbraud]

Describe the bug

When a block opened with ::: contains another block using the same, both blocks are closed by the first ::: encountered. The second ::: is rendered as text.

Steps To Reproduce

0. Use the following in documentation (in my case, a nixdoc comment under lib/) :

   
   :::{.example}
   ## Showcase a parse error in `nixos-render-docs`
   Consider having a note in here:

:::{.note} Note not not ::: :::

1. Render the documentation (`nix-build doc`)
2. Open the result in a browser, navigate to the testcase.

(there's presumably a way to run `nixos-render-docs` outside of nixpkgs' documentation as well)

## Expected behavior

Nesting blocks (without using `::::`) should either cause a parse error, or only the innermost block should be closed by `:::`.

The latter seems preferable, as the `::::` syntax is:
- apparently undocumented: I only learnt of it by checking the source code before opening a bug ;
- significantly less discoverable: while a user may likely intuit that they can nest blocks, needing a different syntax for it came as a surprise (and it remained unclear whether deeper nesting would require `:::::`, `::::::` and so on) ;
- not composable: users must modify blocks when moving part of a document into or out of a block.

## Additional context

Issue encountered when writing documentation for `lib.packagesFromDirectoryRecursive`: #359898

## Notify maintainers

@NixOS/documentation-team

---

Note for maintainers: Please tag this issue in your PR.

---

Add a :+1: [reaction] to [issues you find important].

[reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
[issues you find important]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

[hsjobeki]

Do you have some error log as a reference? I am wondering which tool creates this bug. Nrd i guess

[fricklerhandwerk]

Yes, this is clearly nrd. My hunch is that fixing this will require staring at the code quite a bit (even if the fix will be a two-liner), so the most effective workaround would simply be documenting the intended (nesting with more repetitions) behavior for now. It's not really wrong that it will do the wrong thing if held wrong, so throwing an error is merely nice to have.