Un-maintainable logic behind the XLF trans-unit IDs

Is your feature request related to a problem? Please describe.
The logic under XLF trans-unit IDs is un-maintainable in the context of day to day updating our business code in our Business Central OnPremise instance.

For example, I have a Label inside a Table with its translation from English to Spanish...

After a revision, I refactor this Label to a Codeunit where I had others translated Labels inside a couple of procedures...

The result is that all the other Labels inside Codeunit have now a different ID in .g.xlf file, and therefore, this translations don't work anymore unless I recode all this too.

Describe the solution you'd like
The trans-unit IDs shouldn't change never because breaks any previous translations you have.

Our native language is Spanish, but, because the compiler sets "en-US" by default in .g.xlf we can't set Captions and Labels in .AL files in Spanish hoping to translate the strings into English in an additional way from time to time without our users being affected.

It would be interesting to be able to indicate "es" as the native language of the App in app.json so that the Captions, Labels and other strings could be written in Spanish in AL code and the compiler would automatically generate a file .es.xlf instead of the file .g.xlf that now generates irremediably.

In this way, we would translate the translations from Spanish to other languages like English and not vice versa.

Additional context
AL Language: 2.0.48254
Business Central: ES Dynamics NAV 13.0 (24630) OnPremise

Start by reviewing the XLF trans-unit ID generation described in the issue and how app.json controls generated localization files. Compare the current .g.xlf behavior with the requested stable IDs and native-language output, then identify the compiler or language-service entry points and tests that would need coverage; done means refactoring labels no longer invalidates translations and the configured language produces the expected XLF file.