I understand what you mean by "the Mastodon API" but I think we're talking past each other; this does not seem like a client design problem but a protocol problem.
I would like to contend that the ActivityPub spec is too vague and thus clients are forced to do this "squishing" in order to find a portion of the spec that is sufficiently well-defined as to actually be practical for a specific use-case like a federating Twitter clone.
As far as I can tell, there's an echo of this lack of definition in the ActivityPub (and actually more specifically, in the ActivityStreams) specification if you do a tour of the ecosystem of implementations, you'll find that almost all of them are in dynamically typed high-level languages like Ruby (Mastodon). Implementations in languages like Go where JSON deserialization must be defined per-type have a very hard time with ActivityStreams and you'll find that Go implementations of ActivityPub like go-fed are much more narrowly scoped in their functionality in order to avoid this problem.
I have wasted many, many hours on ActivityPub, and I am extremely sad to make this comment, because I understand why it was invented.. but I'm not sure it's really good enough to achieve its goals.