fwiw, creators of R are Lisp weenies, so you might wanna look there more carefully :-)
It is probably like Michael Spivak writing _Physics for Mathematicians_, because he didn't understand physics books written by physics people. PDF where he explains his troubles with elementary physics: (http://www.math.uga.edu/~shifrin/Spivak_physics.pdf)
Physics explained by lispers! using consistent notation!
In fact it does: http://www.fisica.net/mecanicaclassica/struture_and_interpre...
Nothing really, but I think the code portions of a book like that might be interesting. Allen Downey's book has a bit too much layering of OOP for the sake of OOP for my taste. Check it out if you haven't, he builds up classes for most things where simpler data structures could be used, and ends up wrapping everything in what's effectively a custom API.
Would you do this after starting at a new job, and make this your first commit? Or before contributing to open source?
I could envision some awkward social problems arising there. If you kept that code to yourself, but continued working on the old code, that would probably be frustrating.
I'm just curious because I'm really attracted to the idea of this method but am not sure if it would really work where I'd want it to.
There should be a site with a substantial piece of code to discover and people would answer what were the main (3-5) steps they had to do to ~understand it and how long.
Some of the time the changes are broadly beneficial (like taking a multi-thousand-line file and adding some organizational structure) and it makes sense to commit them upstream. Some of the time the changes are personal preference and aid only in your own understanding of the code.
As with most things, the best approach is to use your judgement, not get too attached to your own changes, and to understand that context matters.
Auditors in E: http://www.erights.org/elang/kernel/auditors/