I don't disagree with everything in the linked post, but some of the commentary is just "make it better", which really feels like it needs more nuance. Render

I don't disagree with everything in the linked post, but some of the commentary is just "make it better", which really feels like it needs more nuance. Render pipelines: URP and HDRP are the two Unity-supplied render pipelines, but they're part of a broader Scriptable Render Pipeline project, which allows Unity or other devs to write render pipelines that interface with the engine in ways that non-core code couldn't previously. The "Standard"/old render pipeline is the default now because most assets are built on it, but iirc either soon or now you'll get the option to select the render pipeline when making a project. "Just make swapping free/nondestructive" isn't really a solution for swapping between arbitrary render pipelines, and not even necessarily a solution for swapping between the two Unity supplied ones. UI: Mostly agree. The layout systems should be better, the masking should be better, the fonts should have been improved in the background as well as buying TMP. Hopefully UIElements is a good solution. Tried to write a React style renderer for UIElements once, but was stymied by the lack of duck typing in C# (without dynamic, anyway). Multiplayer: Totally a mess. Demos: Agree that there's often too much reliance on beta features or engine customisations. The SRP approach mentioned above alleviates some of that. Disagree with "don't make rendered videos out of Unity", I work in ArchViz and it's definitely a direction we're pursuing, due to cost and ease of iteration. There's a very cool DOTS/networking example that Unity has been using internally in Unite talks, and I'm waiting for that to come to stable, because it has a really cool editor interaction story for DOTS, networking, remote devices, etc. DOTS: Lots of the iteration appears to be addressing the author's last point, making the fast solution the simple solution. Transitioning to DOTS with a cleaner API should also help future backwards compatibility, which is a pain point the author identified earlier. Unity's current C# APIs are limited from changing in many ways due to an attempt at backwards compatibility, but a clean break allows you to have better architecture from the start. I guess the TLDR is that I actually do agree with the author in many ways, though I think they're also being unnecessarily harsh and acerbic in places. Lots of things are in a transitionary state, and have been for the past two years, and that's frustrating as a professional working in Unity. That said, if you're building a game using the capabilities and systems in place now, those won't fall out from under you unless you choose to try follow an upgrade path.