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.

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.