> Now, it’s certainly possible that one could develop a new, generative typesetting language that captures the virtues that I’ve discussed above and is free of TeX’s historical baggage.

Like typst?

typst still gets a lot of things wrong.

I have been considering switching to typst, but my main concern has been running into things LaTeX can do but it can't. Were there more fundamental issues you came across?

Would you mind explaining some points typst gets wrong?

As in?

Like sile

Pypy described the following in the FAQ:

> The difference between git branches and named branches is not that important in a repo with 10 branches (no matter how big). But in the case of PyPy, we have at the moment 1840 branches. Most are closed by now, of course. But we would really like to retain (both now and in the future) the ability to look at a commit from the past, and know in which branch it was made. Please make sure you understand the difference between the Git and the Mercurial branches to realize that this is not always possible with Git— we looked hard, and there is no built-in way to get this workflow.

> Still not convinced? Consider this git repo with three commits: commit #2 with parent #1 and head of git branch “A”; commit #3 with also parent #1 but head of git branch “B”. When commit #1 was made, was it in the branch “A” or “B”? (It could also be yet another branch whose head was also moved forward, or even completely deleted.)

In this post they say that "Github notes solves much of point (1): the difficulty of discovering provenance of commits, although not entirely"

The question in your example seems odd to me. It can be interpreted as either 2 OR 3 unique branches depending on how you read it.

There is either base branch A whose current head is commit #2 / branch B with head of commit #3.

OR

Commit #1 is branch “default” commit #2 is branch “A” with parent as commit #1 and commit is branch “B” with parent also as commit #1

Consider your same example with forking instead of branching, how would the issue be resolved?

> It can be interpreted as either 2 OR 3 unique branches depending on how you read it.

The question isn't how many branches, it's what branch the commit was on at the point in time it was created. That's not up to interpretation. It's information that was not recorded.

> Consider your same example with forking instead of branching, how would the issue be resolved?

Forked repositories don't have IDs, don't generally keep track of each other, and there's no way to even count them. So that's not solvable.

But branches do have names, and you almost always make commits onto branches. We shouldn't give up on tracking branches just because tracking forks is hard.

So is this a counter example to Betteridge's law of headlines

If I had a dollar for every product I use with a piece of shit CEOs I'd be a millionare