Dear Unity Developers @ Unity, Sorry, I'm not trying to be a PITA. However, it seems to (dumb me) like it would have been better for Unity and much of the developer community of Unity users if the Unity developers had of updated MonoBehavior for Unity to work in a thread safe environment with the requirement for ECS. Yes, a "completely new way of coding in Unity" (as you say) ECS with the Jobs system will eventually give developers great performance gains. BUT.... In the meantime, why not have created a Unity development path to upgrade Unity MonoBehaviour so it would work in a thread-safe way so all existing code would easily work with Jobs? This seems like the right thing to do for all of the legions of Unity developers who have written zillions of lines of MonoBehavior code as a community and who want to submit Jobs to multi-core machines without a "completely new way of coding in Unity" (as you said, Unity). There is a very old saying, which seems to ring true here: "The Enemy of Good is Great". Updating MonoBehaviour for Unity to work with multi-core machines would have been Good. Creating a Great ECS/Jobs system seems to be the short term (and maybe even long term) enemy of all who have spent years and a lot of money developing in Unity who wanted a working solution in Unity for multi-core machines using MonoBehavior. After all, it's not the Unity customers "fault" that Unity did not design Unity3D to work on a multi-core / multi-threaded environment from the beginning (the get-go, as they say). Isn't is better for Unity developers to fix this problem and make all Unity C# code easily forward compatible with the Jobs system versus forcing all Unity developers to learn a "completely new way of coding in Unity" (as you said) ... ECS? Isn't "The Enemy of Good, Great?" Seems something was not well thought out, at least to me who is not very smart, LOL ECS seems Great; but why throw the Baby out with the Bath Water for ECS and not create a thread-safe jobs system for all existing MonoBehavior code and classes? ?