That is a really good point, and a really good way of phrasing that point, but I still have two semi-objections.

First, I do think this kind of thing falls into a category of... maybe 'polish', for lack of a better word?

This is something that you're not going to notice you're missing until you think "I want to write one of these quick and dirty display clients that I've been encouraged to build over the weekend, and wow, embedded Japanese is just literally impossible to render well." If you have a document format that's designed to be adaptable and flexible, predicting what you're going to need is difficult.

So maybe the idea is that you're not going to throw transcriptions for comics/manga into this, and nobody would need to search documents for embedded passages in other languages, and stuff like auto-translations in a client wouldn't be useful. But to me it kind of just smacks of, "this is designed for the use cases we could think of right now." I don't know what features will be critically important until I try to do something creative, that's why I value a tightly constrained format that's simple to understand but still offers at least some flexibility.

The other objection that keeps coming up in my mind is: is Gemini actually swamped for feature requests right now? Are they being forced to prioritize features? I'll definitely concede that if you surveyed 10,000 people using Gemini, stuff like a hard limit of 2 subheaders is very likely annoying more people right now than anything to do with language types. But Gemini also doesn't look like it's trying to fix its subheader limit. The impression I get from the FAQ is that this is not a spec that's actively evolving much right now.

And that kind of loops me back around to thinking about polish again. On one hand, I'm inclined to think you're right, this is probably not the first thing on anyone's mind. But on the other hand, "a document with multiple languages in it" is a reasonably common thing that will show up in multiple settings. So I'm still looking at a text format that even just on the surface level doesn't seem to be very good at describing text, even in cases where the solutions seem pretty simple. Having a language switch tag in the spec or just allowing multiple top-level media types in the document doesn't seem like it would complicate the parser spec or make it any harder for me to build a client.

Part of this is, if I'm going to adopt a format, I want it to be well thought out -- I want the authors to have spent more time thinking about it than I have. So if I can immediately see problems before I even start using the spec, it makes me wonder what else I'm going to run into where I'll just be scratching my head over why it was designed that way.

On some level I get where you're coming from, and rendering multiple languages is not the end of the world. You can even potentially work around it, maybe. But it would also be very, very easy to get this right, and I don't understand why the first thought from a spec designer putting together a content type header wouldn't be "what if the content type changes mid-document". This is maybe unfair, but the immediate thing that it makes me think is, "these are people who have not spent much time considering how text documents work, even for simple cases."

But if Gemini was in heavy active development, my opinion would probably be different. I don't know, maybe it is? Are they actively evolving the spec right now? Maybe I'm just being over-critical. But I feel like I shouldn't be able to immediately think of use cases involving basic text that Gemini just can't handle, it should take me longer to see the limitations of a general-purpose text format.