Declaring `summary` to have markup other than `text/html`?

Description of issue

name is defined as "A simple, human-readable, plain-text name for the object. HTML markup MUST NOT be included."

summary is defined as "A natural language summarization of the object encoded as HTML."

content includes in its definition that "By default, the value of content is HTML. The mediaType property can be used in the object to indicate a different content type."

So to synthesize these three definitions:

name is always text/plain
content is whatever the value of mediaType is, where mediaType defaults to text/html
summary is always text/html?

But there are cases where a producer might want to signal a different content type for summary; for example, text/plain or text/markdown. Recently, https://github.com/mastodon/mastodon/pull/32538 came up as an example of wanting to produce a summary that is NOT text/html. So the question is, might it make sense to provide a mechanism for declaring that summary is something other than text/html?

Potential solutions

Extending the definition of mediaType to cover both content and summary could work, but would prevent using different formats for each of the two separately.
Defining a separate property like mediaTypeOfSummary seems clunky, but might end up making sense or being necessary.
More explicit construction of a "text node" where every @value can have its own mediaType, although this would be pretty complicated and not backwards-compatible. (It would also break JSON-LD language containers, so nameMap/summaryMap/contentMap would not work.)

Action items

Needs Primer: guidance on the natural language properties, including a section on the content-type considerations (and potential sanitizing/stripping resulting from that)
Next Version: Possibly allowing summary to be something other than text/html, with either mediaType extending to cover it, or defining mediaTypeOfSummary as an analogous property.

I'm not seeing any justification in https://github.com/mastodon/mastodon/pull/32538 for why any content type other than HTML would be useful or preferred. I don't think Claire is expressing any sort of preference for a markdown summary type, just saying that she initially misunderstood it's type.

Adding the requirement to have to process different mime types would have made the PR much more complicated, anyway, than just adding HTML sanitization, since in any case—regardless of what you're producing—you'll have to handle incoming HTML.

this just feels like overcomplicating the spec for no additional benefit. I'm still not convinced there's even a good justification for allowing content to be different media types—are there any major non-HTML implementations?

w3c / activitystreams