Looks okay but when you've destruction issues it's hard to see why destruction order wasn't respected i.e. it shouldn't be happening in the first place if it's rigorously followed.

Once you understand C++ destruction order, out-of-order destructions should generally not happen.

C++ objects are created top to bottom, left to right. Destruction follows the reverse order. This rule is recursive.

What follows from that is an object destroyed earlier can access objects that outlives it (parent objects usually) destroyed later.

Based on the pipelines failure here are the issues we are facing:
Compatibility risk — any CI scripts, build tasks, or tooling that implicitly relied on .NET 6 being present could behave differently under .NET 8. Dependencies between .NET SDK versions and Visual Studio toolchain components can also introduce subtle breakages.

Testing may introduce new changes where there may be compatibility issues with

Image rebuild requirement and SDK 18362 not found (Playground builds) issues.