This is great news:
And Confluence was a piss-poor doc platform. But since your asking for feedback, here are my initial comments...
1. Avoid bad hypertext links
I've seen a couple bad links, in very light usage. For example, on RouterOS License Keys | RouterOS Manual
there is link that returns a 404 from link to:
https://manual.mikrotik.com/docs/Getting%20Started/Installation%20and%20Upgrade/x86-installation.md . Perhaps y'all should use some script to make sure all links are valid when you build the docs so that you'd find them as I didn't not personally verify all links but I ran in on on the CHR pages, as well as on in bridge (although now I cannot remember where), and suspect there are a few more lurking...
For example, it seems Docusaurus support checking them, see https://docusaurus.io/docs/api/docusaurus-config#onBrokenLinks . By default, it produces a warning, but ideally y'all prevent publishing with bad links so they get fixed.
2. Versions by both channels and v7.xx.y (e.g. "development", "testing", 7.23, 7.21.4)
Currently the docs use one version called "current", but agree with others this should be expanded and considered more carefully. First "current" means nothing since docs are based on some version (perhaps 7.23, but IDK). While it may matter slightly less for the narrative topics pages, but the CLI Reference sections certainly reflect a single specific version, since things do change...
IMO docs should be aligned with naming and channel scheme of the releases... My purpose is using "development" and "testing" for the beta/rc's that then get promoted into the v7.2x.y when a release goes to "stable" or "long-term". This allow the docs to be reviewed alongside the development/testing branches. And ideally y'all having some release process/gates that docs should be "complete" before moving to "testing" and certainly before moving to "numbered version" when rc goes to stable
In my purposed scheme here.... only "development" and "testing" be opaque channels, while stable/long-term also use the canonical version numbers... since there is little use for a doc copy for each 7.24betaX...7.24rcY things. With the current stable being the default named version shown.
For example of the problem... 7.24beta1 just changed factory-version to minimum-version so how that be reflected in the new manual site is kinda of "strawman" to figure out how to handle something like that so folks. To @fischerdouglas/other's point, the delta's are actually quite important to know since if you're doing bulk provisioning, it's helpful to know what config may need to be updated.
I doubt "minimum-version" will be the last time some attribute is deprecated/changed/added.... While some callout (" Admonitions" in Docusaurus terms) somewhat covers the narrative pages (e.g. "in v7.24, X attribute -> Y)" and using the "Page History" diffs were historical way of handling this to find (which may in fact not be documented), and the CLI Reference has no way to express a "changed attribute" today.
3. Use "heading id" "document id" to avoid ugly %20 in URLs and provide stable links
The "old" confluence system handled renamed pages with redirects, IDK if the new system does...but right now the URLs are just the page title directly urlencoded including spaces and longer text. Docusaurus seems to support explicit IDs that allow more sane names using - since of %20 everywhere. If third-party tool link to new docs, it be nice to know URL are actually stable, and ideally readable/"pretty" (e.g. avoiding % url encodings)
See https://docusaurus.io/docs/markdown-features/toc#heading-ids and https://docusaurus.io/docs/create-doc#document-id which seem to allow this.
4. CLI Reference URL should be "versioned paths" with well-known heading anchors tags
Related to 3 above, although perhaps some HTTP redirect scheme work too... But it be nice if the URL directly match actually RouterOS CLI syntax. I have several tools like my LSP where I know a RouterOS command but cannot programmatically generated the URL to help pages for a specific known RouterOS path, and it's still non-deterministic in the new system too, For example, the attributes for /ip/firewall/nat are at the rather complex URL:
https://manual.mikrotik.com/docs/CLI%20Reference/system/ip/firewall#ipfirewallnat
whereas it the RouterOS path should be natively in the URL itself, and the #fragment also being well-known "#flags", #attributes, etc). Further, the package in the URL is also a bit problematic since it from a URL POV, all paths a unique but a tool like my LSP or other folks tools/docs may not apriori know package from a in-context command. So some scheme that either redirects based on URL paths that match a RouterOS schema item, or the IDs just match the path/"Directory". For example some scheme like:
https://manual.mikrotik.com/v7.23/api/ip/firewall/nat#flags or https://manual.mikrotik.com/development/api/ip/firewall/nat#flags that go to same page above.
5. CLI Reference pages should show more "metadata" and use <h1...>/#... headers
Flags and Attributes should be under some markdown header
Tables are not URL referenced, so it's hard to link to actual tables with attributes or flags since the generated text does not added a header line above them. So ideally the CLI Reference pages include some "### Flags" before the flags, so that https://...docs/.../path#flags work to navigate to the flags.
Package name in <body>
While the TOC shows the package, it be helpful if that was on the actual page text as well so it clear that from the page text alone what package may be needed. This matters more for LLM readers since they'd have to parse out the URL to know if something was an extra-package but package was in the body, it already know if a package install be required.
Irregular directories/commands
In some cases in RouterOS scheme is not regular so a particular command be not support get/print/set. Perhaps it should like the actual support "primatives" just so it's explicit and clear in docs which commands are supported, especially when they are do not support the full set
"Asynchronous" commands should be noted
Similar to above, some commands like monitor (and others like check-for-updates, /system/license, etc etc). Since often for API you'll need a duration or once, it be better if this was more explicitly shown in some metadata like "Asynchrounus: Yes" so it's parsable without having to infer it from the attributes contain a "once" or "freeze-frame-interval".
For set operations, if "numbers=" allows names
Some commands like /system/script allows the name attribute to be used in a set operations. While other commands require an explicit .id/"print number" only. And others cases, a set may take "name" from a different attribute than just name (like list). So ideally the CLI reference annotate which attribute available as "name" when doing a set. e.g. without some intermediate [find name=XXX] .
Perhaps this could be similar to the "(mandatory)" that added in some doc pages. Although I'm not sure the "(mandatory)" is actually on all pages, as it seems some pages do have a mandatory attributes that are not marked in the CLI reference as such.
6. Export to Markdown
Context7 is mentioned above, but that's not strictly needed since it's raison d'être to provide markdown, instead HTML, for LLM consumption. e.g. since essentially you pay for tokens, markdown is way more "token efficient" since you avoid all the extra XHTML/XML/CSS stuff that is low-value context compared with some ##, <table>, []() etc things. So the actual doc site has markdown and a llms.txt (which is essentially a TOC as plain md text), there no need for the Context7 MCP "middleman". Along with comments in 5 above about using headers also helps a LLM agent to more efficiently use the CLI Reference docs to find the attributes without reading the entire markdown page.
IDK, Docusuarus, but it seem there are a few plugins that directly providing markdown content for a LLM agents that avoid the heavier HTML reading.
e.g. GitHub - FlyNumber/markdown_docusaurus_plugin: A lightweight Docusaurus plugin that exposes your /docs Markdown files as raw .md URLs. (For LLM's and such) · GitHub and
GitHub - rachfop/docusaurus-plugin-llms: Docusaurus plugin for generating LLM-friendly documentation following the llmstxt.org standard · GitHub
And some "Export to Markdown" be useful even for humans and third-party tools too.
7. Shortened URL using https://docs.mt.lv/... —> https://manual.mikrotik.com/docs
Obviously less critical... but since y'all do have the shorten domain, some shorter URL that redirect better avoid browsers/tools getting the ellipse ... when viewing a doc URLs.