I've been a very vocal advocate of Asciidoc as replacement for thick granular XML-based CCS (component content system) specifications, but Typst is the first one that gives it a run for its money. And then some.

If Asciidoc beats up DITA and takes its lunch money, then Typst carjacks it. The CCS capability gap - already vanished with Asciidoc and ReStructuredText - completely reverses with Typst. Typst can do stuff with print that XSL is fundamentally incapable of doing, without plopping the whole thing inside a bespoke Python/JS/TS/etc framework.

For new adopters, unless you have an XML regulatory requirement[1] or an almost fetishistic attachment to Robert Horn's Information Mapping, there is now negative infinity reasons to spool up a DITA instance.

For MIL-STD stuff, the only correct answer is, as always, "Whatever the Program Office Wants", even if that changes weekly. Hey, it's their money.

One downside[2] of Typst, vs Asciidoc, is no published spec. Asciidoc builds out from the DocBook layer, which has more legacy support than most things. The Typst spec is . . . the Typst compiler. But if it gets Pandoc support, who cares?

[1] Which almost always turn out to not be real - read your contracts, people!

[2] There are others. Runtime attributes/variables, better graphing support, tools ecosystem. But those are workable.