> Way too many rewrites fail because people try to "improve" things during the port
I'd say that porting is a great time to "improve" many things, but like you suggest, not a great time to add new features. You can do a lot of improvements while maintaining output parity. You're in the weeds, reading the code, thinking about the routines, and you have all the hindsight of having done it already. Features are great to add as comments that sketch things out but importantly this is a great time to find and recognize that maybe a subroutine is pretty inefficient. I mean the big problem in writing software is that the goal are ever evolving. You wrote the software for different goals, different constraints. So a great time to clean things up, make them more flexible, more readable, *AND TO DOCUMENT*.

I think the last one gets ignored easily but my favorite time to document code is when reading it (but the best time is when writing it). It forces you to think explicitly about what the code is doing and makes it harder for the little things to slip by. Given that Ladybird is a popular project I really do think good documentation is a way to accelerate its development. Good documentation means new people can come in and contribute faster and with fewer errors. It lowers the barrier to entry, substantially. It's also helpful for all the mere mortals who forget things

LLMs are great at producing documentation - ask one "hey can you add a TODO comment about the thing on line 847 that is probably not the best way to do this?" while you're working on the port, and it will craft a reasonably-legible comment about that thing without further thought from you, that will make things easier for the person (possibly future-you) looking at the codebase for improvements to make. Meanwhile, you keep on working on the port that has byte-for-byte identical output.