Broken block-doc comments? (Issue rust-lang/rust#32088 filed, others after dinner. ;)

rustdoc-broken-block-comments.rs

/*!  The generated documentation for a block-doc comment will include asterisks
 * when a paragraph spans multiple lines.
 *
 * Other problems follow.
 */

/// When a block-doc comment is indented, does *not* use an non-alphabetically-terminated
/// fill-prefix, and its first paragraph does not extend beyond the first line
/// of the comment, its subsequent paragraphs are treated as code blocks when
/// indented.  See module's `baz()` fn for example.
///
/// e.g. this happens when you take an indented block-doc comment, and replace
/// all fill-prefix asterisks with spaces.
pub mod a {
    /** This comment is formatted normally, but without leading asterisks.

       Dolor ipsum si amet, blah blah blah blah.  This paragraph becomes an
       indented code block.
     */
    pub fn baz() {}

    /** You're not going to tell me that this is by design, are you?

Because writing documentation like _this_ is just plain ugly.  While there is
a potential ambiguity (i.e., how do you determine the fill-prefix automatically
if the first paragraph is a single line?), some common-sense heuristics (e.g.,
what would the doc text look like if there *were* asterisks aligned
appropriately?) could handle that.
     */
    pub fn ick() {}
}

/// When a block-doc comment is indented and does *not* use an
/// non-alphabetically-terminated fill-prefix, any inline code (using single-backtick
/// pairs) in a paragraph after the first seems to cause a parse error ("error:
/// unknown start of token: `").
pub mod b {
    /** This comment will cause the parse to fail because the parser doesn't...

      ...like inline code in a comment like this.  Placing a non-alphabetic
      symbol, followed by a space, before the offending line's text prevents
      the error (and in this case produces the issue described with `mod a`
      (above)).
     */
    pub fn bash() {}
}