I work in an industry that requires 2 seperate implementations of all critical software components; so I have been involved in several reimplemenations to help satisfy that. There are definitely times where I saw a feature and thought "the original implementation was obviously doing X; and this feature does not really make sense given our architecture". However, I have never needed to rearchitect my program to implement the feature. The only real difference is that a trivial feature for one program takes a bit of work on the other. However, I could also point to functionality that took more work to implement on the original program, that the different implementation made trivial on the second program.

I have only had to do 1 major rearchitecturing, and that was on the original implementation, which had some architectural assumptions that forced an exponential blowup. I'm wasn't working on the second implementation, but they started years after us, and managed to avoid our mistake from the beginning.

To take a public example, that is far more complicated than anything I have worked on, consider the problem of running Windows applications under Linux.

Linux is a completly different implementation of a kernel than NT, and doesn't even attempt to be compatible. However, running Windows applications does not require a rearchitecture. Just a few relativly generic Kernel features, and a userspace compatiblity layer. Not to say that Wine does not take a lot of effort to write and maintain; but not nearly as much effort as implementing Windows itself. And, it is running on top of a platform that never aspired to be Windows compatible. Wine does, however, suffer from the problem that the article points outs, in that it is perpetually behind Windows. Wine also exemplifies a second problem, which is that bugs in the primary implementation end up being relied upon, so in order to be bug-for-bug compatible, you need to first discover what all the bugs you need to implement are.