Hereby the choice of a format for documents of all kinds and related tools is considered.

Requirements


File format type, interaction paradigm


Text files as opposed to binary files

Files are mandatory to be text. Sources must be human readable and suitable for version control practices. It should be easy to convey full text searches with the regular tools.

WYSIWYM versus WYSIWYG

It is of the essence to provide
scalability,
structure control,
consistency,
content and presentation separation
even at the cost of complexity.

Media and multimedia types


Print and digital media

Various electronic devices support should be provided for: desktop, laptops, smartphones, book readers.
All the content forms of text documents, presentations, books, interactive applications should be possible to express.

Interoperability, compatibility, portability

For the cases when a document is handed over to an uncontrolled domain with its own requirements, convertibility must be ensured. Conversion tools, such as pandoc or others, are to be utilized. There is always an "output format" that suits: PDF, Word, HTML...

Features


The format and the tools require support for:
inclusion of:
fragments and components;
images, diagrams, videos...; —
references, including inter and cross;
stylization:
fonts, including custom ones;
coloring; —
layouting:
floating and anchoring,
columns; —
alignment;
indentation and line breaking.

Fragment inclusion facilitates reuse of artifacts. Splitting documents into components eases comprehension.

Text should allow for center and left alignment. Justification might not be recommended but is still a hard requirement for some organizations.

There are several indentation scenarios that suppose control over how text is written versus how it is rendered. Some sources want lines to break on sentences according to their meaning while still grouping into paragraphs, aligning and indenting them automatically. Sometimes all line breaks and spaces are to be preserved as written, such as for addresses or code snippets.

Spread

Display software and tools should be easily obtainable or available by default. Viewing documents offline is required. The format must be standardized and supported.

Alternatives


Word, Writer

WYSIWYG. Binary.

Lightweight markup languages, Markdown


Markdown is quite popular and widely used for writing documentation, readmes, blogs, books... It captivates with its simplicity and is the default choice for many.
Most criticism comes down to weak semantics, lack of scalability and extensibility, absence of the unified specification and split into multitudes of dialects. There is no native stylization, not even basic alignment. For these means it falls back for HTML and CSS.

There are also many clone formats. They try and come up with specifications and different syntax details.

reStructuredText, for instance, has more features, implements elaborate indentation rules and provides an extension interface. But it offers weird Setext headings which makes interleaving them impossible and demand you to match the underline adornment length. It also provides no control over reference URLs for inline targets. And so on...

AsciiDoc. Again, what are some real advantages over Markdown?
CommonMark
Pandoc’s Markdown
Pendown

HTML, CSS and JS


A web browser is advanced software. A lot of effort is put into its development. And what is more important is that everyone has one.

The content is written in HTML, CSS and JS languages which provide almost unlimited capabilities. They are far from ideal. They are just the most common overall due to the ubiquity of the web technologies. Every conceivable design aspect is achievable with HTML and CSS. Dark and light color schemes are toggleable. One can even set the system font to be the default in their browser. And if anything is not there, just resort to JavaScript and implement it.

Browsers are suitable for viewing documents from the file system with limitation that JS requests to local files are blocked. They can even save online pages for offline use. Too bad, none of them support picking up CSS imports from other CSS files.

Reuse of sources is poor: HTML by itself does not follow the DRY principle. Inclusion of local documents is, again, restricted for security reasons. Though the core component model of breaking down into separate artifacts is well worked out.

Full control over indentation and spacing enables choosing how the content behaves on selection and copying. In-content spaces and line breaks can be both inserted manually, just like in plain text, or collapsed automatically. Entire blocks can be indented as well without displaying any spacing symbols. And just like a web application markup indents elements hierarchically based on semantics and layout, documentation is free to focus on the content and treat everything else as service entities.

Speaking of support for various devices, the EPUB book format, for example, uses XHTML.

TeX


A distinctive feature of TeX is its advance typesetting. The popularity of this option is not so wide. But this may be the only pick for some publishers.

There are many flavors, LaTeX and ConTeXt being the main ones. The manuals are well available.

Documentation engines

Some enterprises adhere to the convention of building documentation processes around specialized software. Wikis, other different engines, knowledgebases, like Confluence and Redmine, docsify, Read the Docs and many many others.

Conclusion

It seems like the best compromise would be to just give up on some of the requirements and simply opt in for Markdown. You will be on the same page with the most developers. And if you cant drop them and Markdown does not suffice, well, HTML, CSS and JS are not going anywhere. If you really do not feel like maintaining n meta tags across m documents, an intermediate static generator might help you. And of course, the most interesting solution would be to embed Markdown into HTML. Just need to pick up a JS implementation of a right flavor, that is more or less specified.