Thats not quite the case if you are using Lua strings. All strings are interned and converted to hash lookups (thats all of them). So you certainly do know their sizes and capacity when you go to execute the bytecode (thats when it happens). This is one of the very awesome benefits of luajit (and string buffers in luajit are even more powerful). Additionally in the editor - you would certainly know the size, just like any other resource.
The particular problem I have is related to how I use strings to move data around the framework (which means its a not very applicable use case to most anyway). It is very useful to be able to do this via simple copy/paste mechanisms (from a users point of view) and in editor - the performance benefits are completely moot. Because when you run the build process you can easily capture the property strings and literally use them just like a normal resource (like a texture as mentioned above). I have done this in other luajit systems quite a bit (Ledwerks and Shiva for instance). Its brilliant for localization for example, cos you just pool all the strings into a cache and have selectable hash lookups in lua.
The hashing to put a string into the engine and then get it back out again, I get, would be problematic and I think this is what people are referring to as a performance issue - but I think that this is looking it at from the wrong direction. The string is just a byte array, like a texture… like a shader… like a audio sample… they are all the same, they just have different associated meta data to determine how they operate. Hence, why it seems odd strings are not provided for - as I understand it, it would be as simple as copying say the vertex shader object (which is a text block) renaming it to a strings object and blam - you got strings. Add a “New strings file” to the resource pool voila.
I know I have said the above a couple of times. I’ll leave it at that. And sorry @Mathias_Westerdahl if this has been a bit ov erkill. Its one of the extremely few ‘odd’ things I have come across in Defold - and honestly this is more about user editor front-end simplification not technical underlying issue (theres a number of ways around the problem, they are just a bit more messy for the user).