Feature-request: split the strings.xml for in-device and settings related strings

the resource table is loaded in memory, and there's no entries for those strings

Exactly.

App can't crash because you can't build it  (Undefined symbol ':StringSymbol' detected).

In my case, it can, because of the way I access the strings. I have

(:typecheck(false))
function loadString(string_id as Symbol) as String {
    return WatchUi.loadResource(Rez.Strings[string_id] as Symbol) as String;
}

And then I call loadString(:my_string), rather than WatchUi.loadResource(Rez.String.myString).

Each call to loadString generates much less code than the corresponding call to WatchUi.loadResource would have done (saves 5 bytes for the call itself, and 14 for the argument) - but yes, I guess it does have the downside that it subverts the compiler's undefined symbol checking.

But I'm curious how it works since it's from 4.2.x:

No device needs to know about the new "scope", because anything with that scope is left out of the .prg file. Settings still work because all the information about the settings is (and always has been) encapsulated in the MyApp-settings.json file (which is sent to the store in the .iq file).

In other words, as discussed years ago, it's a compile-time change which every device can benefit from.

To be clear, I also tried fr955 with the same results (strings with the settings scope are excluded from the PRG).

So  I think the memory savings comes from when an app calls loadResource() (at least once), the resource table is loaded in memory, and there's no entries for those strings. (I think you'll just save a constant amount of memory per string, since the resource table only has resource IDs as values, not contents)

Brandon.ConnectIQ Thanks to the CIQ team for implementing this! This is something I've wanted to see for years.

But I'm curious how it works since it's from 4.2.x:

I would guess that it just builds all the PRGs without the string resources specified with the settings scope. Any resource string that's only for settings would only need to go in the metadata that gets sent to the store for use by the Connect app.

I tried it myself: added some strings to a demo project, built the PRG for fr235, then changed the scope for those strings to settings and built the PRG again. The 2nd PRG is smaller, and a hex diff of the two files shows that the first PRG contains those strings and the 2nd one does not.

In other words, as discussed years ago, it's a compile-time change which every device can benefit from.