Here's a brain dump of where I stand on docstrings and related topics.

Text can be plain text or markup.

In source code, plain text is represented as a string.

Markup embedded in source code can be either:

- Parsed from a string literal.

- Encoded as S-expressions, using e.g. SXML.

- Encoded using tailor-made lexical syntax, e.g. XML literals in Kawa.

Documentation is text.

It makes sense to encode text either for documentation purposes or for
other purposes (e.g. writing it into a file as a web page). In each
case the structure of the markup (if any) is identical. That means the
same lexical syntax should be used in both cases. There should not be
any special lexical syntax for documentation.

It makes sense to have lexical syntax for text markup languages.

A contrived example:

   #markup("# Title

            paragraph")

Documentation attached to a part of source code could go under the
more general concept of declarations or metadata. Common Lisp and
Emacs Lisp have declarations; Clojure has metadata. It could be argued
that declarations are a kind of metadata. (Declarations are for the
compiler and interpreter, whereas metadata is for the application, but I
suspect the distinction would get muddy eventually.)

Common Lisp and Emacs Lisp have docstrings like so:

   (defun some-function (arg1 arg2)
     "Does something with ARG1 and ARG2.

      Use with care."
     ...code here...)

In these languages, f a string literal is at the beginning of a function
definition, it is considered a docstring. This works reasonably well,
and I would advocate copying docstrings and declarations from Common
Lisp into Scheme (with modest changes).

If we had text markup literals, they could naturally be used in place of
string literals to write documentation:

   (defun some-function (arg1 arg2)
     #markup("
     Does something with _arg1_ and _arg2_.

     Use with care.")
     ...code here...)

or in Scheme:

   (define (some-procedure arg1 arg2)
     #markup("
     Does something with _arg1_ and _arg2_.

     Use with care.")
     ...code here...)

It's not clear how to best represent a markup fragment as a Scheme
object. It probably should not be a subtype of string.