Normally such changes will only show if the source file was changed. Maybe the resource that holds those string was changed?

If you can share the source files and the LPU you can raise a support case and ask the support team to identify what is changed.

>> Maybe the resource that holds those string was changed?
As I said, "No new strings, none changed, none deleted, and the resource IDs were unchanged.". But the assembly was recompiled.

In the meantime I heard from other users that this is a known issue with Passolo and is currently under investigation at RWS.

In case someone else hits the same problem, the workaround they use is to back up the original .lpu file, then update the string lists, then recover any lost translations by Passolo leverage from the backup. Works, but inconvenient.

What I also found is that translations don't get lost if the .lpu file is updated during our build in batch mode. There we call pslcmd.exe with parameters "/update /generate" where "/update" is documented as "Updates the source string lists and translation lists.". So the lists are updated but translations remain. So far I've only reproduced the problem in GUI mode.

Where have you heard or read that this is a known issue? I would be interested in it.

When saying "No new strings, none changed, none deleted, and the resource IDs were unchanged." it might not be the full story. The .NET parser is creating something called a full qualified identifier and beside string IDs the full resource ID and other data is used for it. Just re-compiling will not result into the described issues, but developers are something doing a refactoring in their modules and this changes the identifier resulting into the observed behavior.

Passolo doesn't know what developers have refactored, as Visual Studio is not storing any refactoring information that could be used by Passolo. So Passolo is creating new string entries. The work-arounds were already mentioned in your post. You can use Leverage when the old project is still available or pre-translate from recycle bin as TM when you updated the only existing project.

As best practice, developers should notify localization managers when .NET modules are undergoing any refactoring.

In the meantime I have found out a bit more. It appears that I made a mistake by updating my source files with assemblies that had already been passed once through Passolo.

The first stage in our translation process is a translation from English to English ("developer English" to proof-read English). Thinking that proof-read English was better than our "developer English", I used the target files of this first stage to update the source files. This caused the problem.

If I update the source files with assemblies that come directly from the build (before localization), the problem does not occur.

I was also wrong about the influence of Passolo batch mode. With the wrong source files I reproduced the problem in batch mode as well.

I still don't know what my Passolo project does to the strings so that they are not recognized as the same strings when re-read, and whether we should change something about our .lpu or our source. But the question is not really urgent, now that I know which pitfall to avoid.

We work with cascaded projects.
In the basic project, we translate internally from the developer language into our source language for further translations (in our case: German).
In the extracted project, German is then translated into all other foreign languages (and also into correct English).
The update is then automatically correct.

Yes, that's what we do too, except that our base language is English. But I lost the translations already in the base project. And once they are lost in the base project, consequently they will be lost in the cascaded project as well. That's what made the matter especially inconvenient. But the remedy is clear: when updating source files in the base project, use freshly built, non-localized binaries.