We're at the point in humanity's development of computing infrastructure where the source code for program texts (e.g. a module definition) should be rich text and not just ASCII/UTF-8.
Forget that I said "rich text" for a moment and pretend that I was just narrowly talking about the inclusion of, say, graphical diagrams in source code comments.
Could we do this today? Answer: yes.
"Sure, you could define a format, but what should it look like? You're going to have to deal with lots of competing proposals for how to actually encode those documents, right?" Answer: no, not really. We have a ubiquitous, widely supported format that is capable of encoding this and more: HTML.
Now consider what else we could do with that power. Consider a TypeScript alternative that works not by inserting inline type annotations into the program text, but instead by encoding the type of a given identifier via the HTML class attribute.
Now consider program parametrization where a module includes multiple options for the way that you use it, and you configure it as the programmer by opening up the module definition in your program editor, gesturing at the thing it is that you want to concretely specify, selecting one of those options, and have the program text for the module react accordingly—without erasing or severing the mechanism for configuration, so if another programmer wants to change the module parameters to satisfy some future need—or lift that module from your source tree and use it in another one for a completely different program—then they can reconfigure it with the same mechanism that you used.
