My two cents (also presented elsewhere). Providing capability also means providing documentation, then wider API access and so on. The problem with Unity devs and other people skilled in other engines coming to Defold means they want the same capability in the engine. Language isnt really the issue, its the platform people use to garner support to end up with a large group trying to sway opinion - this is exactly what happened with Unitys own script and JS back when they had three.
The engine and maintenance requirements for that is enormous as the engine grows. Its not so bad when things are smaller and relatively simple. Then the larger groups end up moving the dev (sure to market and business considerations) and you ended up with Unity3D with C# using Mono.
Then, and imho this is the actual problem coming down the track, if you need to support C# it is not the language that matters, its how easily Unity people can jump in and use it in the same way they are skilled with (from Unity) meaning, you will have to implement features that are more aligned with the Unity engine that is accessible in C#. This might not seem important if the focus is on Lua and C++, but managing expectations means that the engine will expand to cater for the C# additions and thus impact how the engine works for its original languages. Again if you worked back when Unity3D first started, you will recognize this problem and resulting impact.
These are slow moving group and system design issues that are 5->10yr development cycles and they are often business driven and not technical driven. I remember talking with Unity devs in the early days and they did not want to go the C# and JS route because of the runtime nightmares and engine interface nightmares. With a large body of people skilled in Unity that will influence what happens to Defold if the business and economics line up for it to do so.
For me. Im very wary of this. I work in industries where software stability is extremely important. And we have models and sims in defense that are in excess of 30 years old, written in languages like Ada. These systems dont get changed because the development cost, maintenance and security cost is far too high to do so.
I personally see Luajit as one of the most stable, flexible, performant and long term solutions that has already stood the test of many industries and thus makes an excellent choice for the businesses I work with. But, I understand the game business is very different, and so there was always a risk that Defold may have changes and mutations that might impact this potential.
The need to support multiple languages I dont believe is actually necessary. Thats my own opinion. After building systems for companys with Go, Rust and other newer languages theres is a clear over zealous need for people to use modern lang X over the sensibility of just getting the work done. Entire industries have been created for language bases alone, and they need this propagation to survive (people always forget the vast amount of languages that come and go).
I personally like how Defold is sticking with Lua and C++ - these are good long-term strategies that have already stood the test of time. No-one can claim Go, Rust, Odin, Zig etc will be around in the next 10 yrs, thus committing to them is not a good idea for an engine with a long lifespan. C#, I think is a more problematic one, and I suspect its influence will change Defold (I dont see how it wont) and this is my current concern for the work I want to keep developing.
Sorry about the rant. Its a topic that is both complicated and often for many people emotional, because they often dont look at the history or the engineering needs and just at the evangelism behind a specific languages marketing. There are ways forward with Defold atm, and for the time being it will still be my go to system to dev with.