"rewritten the majority of its source code with web standards and interoperability with other modern browsers in mind"
I think coldtea is focusing on highlighted part. A rewrite like that might change so many behavioral aspects, esp user- or developer-visible, that it can be considered a new engine rather than mere clean-up of behaviorally-identical old one. I certainly reuses some code and techniques but differences might be major.
At the same time, depending on how the rewrite was carried out, it may be nothing like a completely new project. Rewriting function by function is different than rewriting component by component, which is also different than rewriting from scratch.
Rewriting function by function will give you largely the same program using largely the same algorithms, but possibly with more or less bugs, or cleaned up code.
Rewriting component by component will allow new ways those components are implemented, but the interface between components will likely be the same.
Rewriting from scratch could yield anything (servo could be classified as a way to rewrite gecko from scratch, I believe).
All of these could be said to have had the majority of their source code rewritten, but I would only really consider the last one to be "new" without knowing further details. Of course, the devil is in the details...
It's why I'm focusing on behavioral aspect: what does the software do? A browser fork that behaves very differently from prior one to point you have to change existing code to get same effect is essentially a new app at behavioral level. However, it might have same name and lots of same code inside. At that level, it's old code in an old app. We largely define our components by their interfaces and behavior. So that's what I'm focusing on.
Sure, but if it behaves significantly differently, then I think that precludes it from being a function by function rewrite. At the same time, a component by component rewrite can be a complete rewrite (but it depends a bit more on the details, I think). If the mainly user visible portions are rewritten, but much of the utility code and other components are not, it may appear behaviorally different, but but be largely the same code base. It's much harder to know, looking in from the outside.
For a simplistic example, say someone provides a "rewrite" of grep. Maybe the options are all different looking and sounding, so it may appear to be significantly different. But if the core of the matching algorithm and it's capabilities are largely unchanged, is it a that much of a rewrite? To the outside user it may superficially appear so, but to someone comparing the source from before and after, there may be an entirely different opinion, and even that may change if you come from a context of focusing on a particular aspect.
As applied to Trident/Edge, we may have a case where the person speaking was involved in a project to rewrite one major component of the browser, and so is speaking in that context. Maybe that component is responsible for about 60% of the code and functionality, but it still relies on a quite a bit of largely unchanged additional libraries. It's very subjective as to whether you think that qualifies as a rewrite of the project, and depends quite a bit on what was not rewritten, and what you think of that code.
I'll mostly agree with that. Harder to do looking at assembler. However, at behavioral level, you can just black box it to see if it passes acceptance tests for desired outputs. If it does, it might be same for your needs. If it doesnt, it's clearly a problem.
Your point applies totally if we're talking the How instead of the What.