Hrm. From an architectural pov, I see that as a very different issue. Please note I am making a number of assumptions about the source code, so if Im way off, please correct me.
As I understand it, there is a basic loose coupling between gameobjects and components (ie you dont have to have them). As a script is essentially a type of component, the designation of a property within the script to be mapped to a gameobject should be quite trivial, and be completely referenced (much like resources I assume should be), so referencing a string should be no different. Thus the why I feel the ‘performance’ criteria seems a little misplaced. More importantly, if you use pure lua text then the cost should be extremely minimal, and you could easily automate string pools (Ive done this myself in luajit systems) allowing you to track and and manage heavy string workloads, if there are any, at runtime.
Again, this makes many assumptions about the underlying SDK source. From the editor perspective, components like cameras I would also expect to be referenced, but they are also a very different type of component and thus would be managed as such. I dont think its either bad or otherwise that you have a number of properties that reference each other, engineering wise, it really doesnt matter. What I think (and remember, just my opinion) is that editor priority would be squarely aimed at allowing users to feel comfortable using the system How that actually happens is far less important since it can be massaged when packaging resources and compiling scripts.
If I were to do something like this, providing base lua types (because remember this is coming from a script - properties that is) number and string seem like a very straight forward thing to support. Supporting a selection of Defold specific object (userdata I assume) types like vector3 etc makes good sense, theres no need to expose everything. Having vec4 limited to a color picker does seem a little odd - but I suspect that is because there is no “color” type specifically which means determining the use case for the property just from the userdata would be tricky - maybe add a color type in name only, and have it cast to vec4 on property use?
Anyway, its worth chatting about this, but I think I really need time to get into the source which I intend to do soon. Then I’ll be able to make more sensible suggestions 