I also don’t like the idea of using contentMap for this, but I think trying to define fallback behaviors will never realistically work - we cannot predict what clients will want to do, and any set of fallback behaviors would ultimately end up privileging a very specific subset of what it should be possible to develop, especially from the direction of trying to represent “recommended” HTML representations.
I think my preference would be to extend source instead as sourceMap which is a less serious semantic violation of intent than using contentMap for media types instead of language, and would have the added benefit of clients being able to do a limited amount of type negotiation for things like editing posts where maybe they don’t support the actual original source (like the org mode example in the spec document), but this makes the relationship between source and contentMap (for languages) even less clear, and could have complications for updating multiple source formats from a single “real” source format, where the internal content for some formats could lag behind others if the client or server doesn’t support one of the sources stored.
End of the day, I don’t think there’s any ideal options here, but I don’t think there’s any reasonable way to handle specifying fallback behaviors for full-featured HTML in content - we’d need some additional way to know which subset of HTML the thing is targeting, and even knowing that you’d implicitly also need to know what type of app it is – the structure of the HTML is always going to reflect the type of application that the HTML was generated for/by which may not apply in an app that may have an easier time coping with the result if alternative representations were provided.
The only other option I can see is using additional parameters with HTTP content negotiation to allow requesting json-ld documents with specific types in the content fields, which may also work and would avoid exploding the json representation with a bunch of types, but we’d need to pick a scheme for representing the types there, and make sure that there’s a way for clients to detect that they got back a different type than they requested if the server falls back to HTML.