OK so I had a closer look, removed some stuff and I strongly believe that things should behave as expected, but looking a lot sexier ?
Please review.

I have tested this item ✅ successfully on 7a389f8

Before the patch the wrong file was shown as having the missing string, after the patch the missing string is shown with the correct filename.

@elkuku Tested and fix is good.

Have some untranslated strings

how to get untranslated Strings?

how to get untranslated Strings?

On a fresh install, modify /language/en-GB/en-GB.mod_breadcrumbs.ini
Change
MOD_BREADCRUMBS_HOME="Home"
to
MOD_BREADCRUMBS_HOMEx="Home"
and sail to your frontpage.

This will give you not only an untranslated string but also an "error" ?

I have tested this item ✅ successfully on 7a389f8

Thanks for Help, @elkuku.

Ready to Commit after two successful tests.

I did some additional changes while discovering more instances..
Please try the global configuration in backend which uses some "uncommon" methods in (J)Text...

@roland-d @franz-wohlkoenig would you mind testing again? Thanks and sorry for the noise..

Please try the global configuration in backend which uses some "uncommon" methods in (J)Text...

Can you give Example of "uncommon Methods" which should be tested?

@elkuku
Although it is better indeed than before, results are sometimes weird.
Example when the error comes from a string in a field as the path will display the library/src/Form/Field/ whateverfieldfile, or for other errors, other files in library/src/

Maybe better than nothing. I let other people decide.

@infograf768 I don't fully understand the problem. Can you explain the issue somewhat further?

It is not a problem per se, it just is not really helpful when the string is used in a field.

Com_config is a good example.
Let's say I take off a double quote here
COM_CONFIG=Configuration Manager"

Then look at debug.
Parsing errors is correct
JROOT/administrator/language/en-GB/en-GB.com_config.ini:6

Then look at Untranslated strings:
Among all chapters there we have

# JROOT/administrator/components/com_config/View/Application/HtmlView.php

COM_CONFIG_GLOBAL_CONFIGURATION="CONFIG GLOBAL CONFIGURATION"

which corresponds to
ToolbarHelper::title(Text::_('COM_CONFIG_GLOBAL_CONFIGURATION'), 'equalizer config');

Therefore this case is real useful as you know precisely where the string is used.

Now look at other chapters of Unranslated strings
I choose here 3 of the smaller ones:

# JROOT/libraries/src/Form/Field/PasswordField.php

COM_CONFIG_FIELD_FTP_PASSWORD_LABEL="CONFIG FIELD FTP PASSWORD LABEL"
COM_CONFIG_FIELD_MAIL_SMTP_PASSWORD_LABEL="CONFIG FIELD MAIL SMTP PASSWORD LABEL"
COM_CONFIG_FIELD_PROXY_PASSWORD_LABEL="CONFIG FIELD PROXY PASSWORD LABEL"
COM_CONFIG_FIELD_REDIS_AUTH_DESC="CONFIG FIELD REDIS AUTH DESC"
COM_CONFIG_FIELD_REDIS_AUTH_LABEL="CONFIG FIELD REDIS AUTH LABEL"

# JROOT/libraries/src/Form/Field/TextareaField.php

COM_CONFIG_FIELD_METADESC_LABEL="CONFIG FIELD METADESC LABEL"
COM_CONFIG_FIELD_METAKEYS_LABEL="CONFIG FIELD METAKEYS LABEL"
COM_CONFIG_FIELD_OFFLINE_MESSAGE_LABEL="CONFIG FIELD OFFLINE MESSAGE LABEL"

# JROOT/libraries/src/Form/Field/MediaField.php

COM_CONFIG_FIELD_OFFLINE_IMAGE_LABEL="CONFIG FIELD OFFLINE IMAGE LABEL"

The information concerning the location is useless as the strings are not physically present in these files but in xml(s).

Hello @infograf768 thanks for chiming in here as this issue really requires the opinion from a language expert ?
Of course you are right that the current solution is not perfect and if, for example, a (J)FormField is displayed this information is pretty much useless.
I believe the only real option to examine from where a language string is "called" would be to include the whole stack trace and not only a "guessing" of the caller that might be different with thew next change of a name space or directory...
If #20380 gets merged I think we could make this happen.

I disagree that the formfield would not be a valid hint for the user. It is very helpfull for me when developing my own fields. Otherwise cool find. ?

It is very helpfull for me when developing my own fields.

Well, it just tells you the problem is in an xml. Useful indeed for a dev creating an extension as xml(s) quantity is somehow limited.
When dealing with the whole core, one has nevertheless to grep for the missing string. No p.

So I just surfed around the docs, looking for information on debugging Joomla! and found the following page about language debug: https://docs.joomla.org/index.php?title=Debugging_a_translation

Here you can read at the very bottom:

Note that the path shown is only a best guess based on a call to the PHP debug_backtrace function. Sometimes it is accurate, sometimes it is not and there are also cases where no file could be determined. In those cases you have to use your best judgement.

@chrisdavenport wrote those words back in 2008 and they are still valid ?

And that's why I decided to include the whole stack trace to help judging. See: #20380 (comment)

So. if we get another tester for #20380 and get it merged this here can be closed.

Since #20380 has been merged, this can be closed. Thanks @all for testing!