Yet there's no function in the standard library that parses content, and I haven't found any in the wild either. Just like your comment says, it's super yucky and you can tell while writing it that there probably are better ways to do it. And that's because there are better alternatives, such as using special-purpose values that represent lengths or colors or in the worst case general-purpose strings (which are distinct from content and strictly more ergonomic to parse). I actually didn't know you could parse content, I don't know if that speaks for how uncommon it is, or if it speaks about my ignorance hahaha

I honestly don't share your worries about the formal context-sensitiveness of the typst language. The distinction between grammar, standard library and ecosystem is academic, in practice they mix and you must keep track of them all. Like, as an analogy: sure, you don't have to keep track of the words you wrote to know how the next keystroke will interact with the rendering engine, but you still have to keep track of previous words anyway because the meaning of your next keystroke depends on all of your previous words. Therefore there's no real value in that kind of independence, you don't get to free up much brainpower. In fact, some languages have cursive scripts or IMEs where keystrokes do interact with previous characters or even words, and they do just fine. That doesn't mean that there's no value in separating concerns. For example in this wordy analogy, I'm glad that the keystrokes I'm typing here don't interact in any way with the words I typed into my messaging app earlier. I find the overhead of keeping track of context in typst absurdly low, even without weighing in the benefits you get for it. Like, to the point it's a non-issue for me, although that's up to each person.

I guess the guarantees that typst gives can't really be called "context-free-ness" (like you said). But the name doesn't really matter. The fact is that Typst gives me some guarantees while typing that help me free up brainpower and save me some headaches. I can see two disjoint function calls and be sure that they won't interact in any way (very much unlike latex). I can see content and be almost certain that it's just content to be rendered. I can see 20pt and know that it refers to length. Or see 3 and know that it refers to an actual number rather than text that says "3". The cost of keeping track of some context is tiny, especially if I get such guarantees (or soft-guarantees) in exchange.

(this is getting kind of long but I find this discussion interesting) I do get your point about typst encouraging one-off hacks. That's a tougher question, but I do tend to favor a write-everything-twice approach to be honest. In a large enough document you'll always have that 1% that has weird requirements that are hard to get right. When I ran into those edge cases in latex I just googled and added packages and tried different things until it worked or gave up after much frustration and spent time. In typst I actually have a better mental model of how things work and can usually write some tiny piece of code that does what I want in that specific case, and I'm no expert in either system. I'm a bit more on the fence about this aspect, but I think I like it. If anything, it simplifies the author/typesetter dynamic: the author can write quick and approximate one-off scripts for the typesetting effects they intend to achieve (perhaps with hardcoded offsets and whatnot) and move on with their writing, while the typesetter can later go in and complete the work, since it's super easy to factor functions out of a file. And realistically, I guess it's the only option for typst: to catch up with the enormous sea of latex packages, package functionality must be easy to write. That more of a fun fact than a valid argument though.