Got one in the mail yesterday (check was written Feb 10). In fact you can figure out how many checks were written in the last month, roughly: compare https://web.archive.org/web/20200110074014/https://cs.stanfo... with https://web.archive.org/web/20200219035903/https://cs.stanfo... I imagine most of these checks (definitely all $7 of mine) were from finding bugs in pre-fascicles, i.e. bleeding-edge drafts he's been putting up online. (See near the bottom of https://cs.stanford.edu/~knuth/news.html)
On the other hand, while you mention Knuth and "done", TeX and METAFONT are better examples. He declared them "done" in 1990 (https://tug.org/TUGboat/Articles/tb11-4/tb30knut.pdf), but still does bug fixes:
> I still take full responsibility for the master sources of TeX, METAFONT, and Computer Modern. Therefore I periodically take a few days off from my current projects and look at all of the accumulated bug reports. This happened most recently in 1992, 1993, 1995, 1998, 2002, 2007, and 2013; following this pattern, I intend to check on purported bugs again in the years 2020, 2028, 2037, etc. The intervals between such maintenance periods are increasing, because the systems have been converging to an error-free state.
(The latest round, in 2013, did surface one bug: the debug string representation of an "empty" control sequence was missing a space.)
> I imagine most of these checks (definitely all $7 of mine)
The 0x$2.00 check I got from 10 Feb 2020 was for one typographical item in Volume 4A and one pedagogical improvement in Volume 1, Fascicle 1. So it is certainly possible to still get checks for material that is already published.
Since it is now 2020, anyone with bug reports from the typography stuff should send them in soon, wouldn't want to miss the deadline.
- On page 715 of Volume 4A, he had something like \`a when he meant to have just à.
- In Volume 1, Fascicle 1, there is a convention that the "main" entry point of an MMIX program begins at LOC #100. The convention is established early on and repeated throughout the text. However, at no point is it explained why LOC #100 was chosen (instead of LOC #0, LOC #80, or whatever). It could be gleaned through careful study -- LOC #0-#80 are reserved for trip/trap handling and one more location before #100 is reserved for a special second entry point -- but you basically had to read the entire fascicle to find /all/ of these. A naive user would be likely to try writing a program beginning at LOC #0 and wonder why it didn't seem to behave correctly. My suggestion was to just add a note explaining why LOC #100 was used. He agreed and you can find the added note in the latest errata for Volume 1, Fascicle 1.