Lets give @anntzer a few days and then merge this.

I didn't look super carefully (may be nice to figure out what exactly is TeX's behavior) but I guess this inserts a space in \sin^n x or in \sin\sqrt x where we may not want one?

@anntzer You're correct; I forgot about those cases. The space before the subscript / superscript can easily be handled by also excluding _ and ^, which is a change I just made.

According to p. 170 of the TeXbook, space is always inserted after an operator except when followed by opening / closing atoms (parentheses, etc.) and punctuation. This means that space should be inserted before \sqrt. It also means that the thin space should actually be included when there's a subscript / superscript, but it should be included after the subscript / superscript. I verified both of these with TeX.

However, I'm not sure how to put the thin space after the subscript / superscript, since I haven't quite figured out how that code works.

1. I'm very much just armchair-quarterbacking here, but perhaps if the next token is sub/superscript then set a flag saying "after this sub/super (possibly both sub and super, if both are present), check whether a thin space should be added"?
2. I guess the same logic (with or without sub/super handling) is also needed for operatorname (just below)? (Should function just be implemented in terms of operatorname, i.e. replace the whole body of function() by hlist = self.operatorname(...); hlist.function_name = toks[0]; return hlist, and just put the thin space logic only in operatorname?)
3. Regardless, this is clearly an improvement, and does not preclude implementing sub/super handling later, but my guess is that at least we could try handling operatorname in this PR (i.e. I'm not insisting on 1., but perhaps on 2.).

I extended the improvement to include operatorname. However, the tests are going to fail now because the old rendering of $\operatorname{cos} x$ was incorrect.

I guess it would be reasonable to just get rid of the single failing test as it's behavior is effectively being tested by the check_figures_equal test.

With regard to subscript / superscript, I can easily determine in the subsuper parsing function that the nucleus is an operator. However, I can't figure out how to determine how many characters make up the full subscript / superscript expression, so I can't check what follows to determine whether or not a thin space should be inserted.

I updated the commit that dropped the test to also drop the corresponding baseline images.