Possibly not what you're looking for, but: the things I've learned while grading are mostly pedagogical, not new mathematical facts (in fact, teaching at a community college as I do, I'm not sure that's ever happened).
One of the main things that sticks with me is this: The rather incredible kaleidoscope of ways that students can misunderstand or be wrong about a thing. Generally the faculty in my department push the thesis that all-multiple-choice testing is fine (even required) for most courses up to calculus, say. The instinct is that it's "obvious" what the common mistakes might be, and these can be covered in a set of 3 or 4 distractor options.
Now, I'm one of the very few instructors (maybe the only one now) who insists on at least a few open-ended questions on any of my tests to see what student work is actually like (and give feedback on it). In doing so, I've discovered a whole lot more "ways to be wrong" then I'd ever imagine, or that could be covered in a multiple-choice test. Looked at from another perspective: any multiple-choice test is an enormous safety net, because it actually rules out the great majority of student responses.
One example: On a college algebra test a few years back, I asked: "Write the equation of the line, with the given properties, in slope-intercept form: Through (-2, 6) and (2, -7)". Out of 40 test submissions, I found there were 26 different unique responses. (!) More specifically: 14 students got the right answer, 2 students duplicated a certain wrong answer, and 24 students each had a unique wrong answer, duplicated by no one else. (Which brings to mind Tolstoy's adage, "All happy families are alike; each unhappy family is unhappy in its own way.")
Second example: For the first time this semester I'm giving programming tests on an actual computer in our lab. (For 20 years I gave programming tests on paper; transitioned to online tests for the COVID pandemic; and found enough advantages that I wanted to keep that as we switched back to in-person teaching.) Coincidentally, the lab has screen-monitoring software that's always on, so without planning it I found myself watching students write code in real-time on a test for the first time ever. I was amazed at how many of my second-semester CS majors couldn't write even basic structures; several were taking many shotgun attempts at simply declaring an array, or couldn't even write a simple for loop, for instance (e.g., mixing up bits of syntax between while, for, and do-while loops, taking as many as 10 minutes of iterations fired at the compiler trying to get it right). One student apparently actually memorized the entire practice test solution, typed that in first (with great difficulty and many compiler errors), and only once that was running tried to modify it to match the actual test question.
Pretty fascinating stuff which I'd have never known if I didn't get to see the students' actual work process.