Following it from the outside looking in, it seems like the main issue is that Unity doesn't actually understand the work involved in maintaining an engine -- they're viewing it as a "the tech is better, so people will naturally switch" situation, versus a "the tech is better, but mountains of effort exists based on the previous tech, so changing tech requires an upgrade path, or no change at all" situation

akin to the MSDN Magazine camp of joel's portrayal of microsoft (Chen vs MSDN): https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

So they end up building parallel implementations, rewriting from scratch, not realizing that they'll eventually have to maintain both implementations or lose a large chunk of their userbase (unless they're so well-embedded that the userbase has no other option, which I don't think is the case). When they finally realize it, its too late... and probably even leads to a drop in assigned resources furthering the delay till release of the implementation

My guess it's more along the lines of the problem of marketing the new shiny to new users or new projects vs supporting the existing users. In a perfect world, they would build the new shiny and their existing users would switch (which it sounds like they keep pushing for) and their hopeful new users would be happy seeing the new shiny stuff.

The real world means you have to support both for some long period of time, because your existing users won't and many times can't switch because of myriad reasons you didn't think of, and if you can't both support the old and build the new, you have problems. Like this.

Not only did they decide write a new render rather than evolve their existing one, they wrote two. Now we have to choose to stick with the old render that we know, or evaluate two new ones and try and pick one.