Thanks for sharing your understanding and concerns, @dKleinTriCAT .
Regarding the asset corruption, the package manager has not really changed how it updates packages. It still just fetches and deploys files to a folder under Library/PackageCache, then tells the Editor “here be packages, please import their files”. It does not itself import anything, “load” anything, trigger any compilation, etc. These are decoupled steps executed by other subsystems of the Editor, which are triggered later during the Asset Database refresh process. Therefore, any problem with asset state mismatch between what’s on disk and what’s been actually imported really lies elsewhere. That said, this change (i.e. the Editor no longer aggressively reverting changes by making the Package Manager re-resolve packages) is probably correlated with other changes in asset importers, import/compilation/scripting/build pipelines, etc. which could make it seem like it’s involved: when the warning is logged, it means the Asset Database finished importing the changed file, therefore the modified file was fully processed by its importer. That said, if you are ever able to create a repro project, or know about specific versions where you didn’t have the issue and now do, you should definitely report a bug with this project and/or information and we’ll definitely look at it.
Regarding the change in how we handle immutable package modification, your understanding is correct. We now log warnings instead of immediately triggering a Resolve Packages operation. Just to clarify, this was introduced during the 2023.2 Alpha and not backported to previous releases, so it doesn’t affect 2023.1 or any 2022 LTS version. If you encountered the corruption issue in any of those versions, then it’s a proof that it’s not related to this change in the handling of immutable package modification.
I understand - “But it works on my machine!” issues are definitely very annoying to troubleshoot. I’m still not sure this change will lead to massively more occurrences of such issues, at least if your users pay attention to warnings (which will pop-up every time a modification occurs) and automated tasks flag them as problematic.
To be clear, I fully support the idea of somehow labeling or flagging packages as altered, with an easy, efficient way to revert individual packages. I’ll definitely pass this on to the product team.
Thanks for your suggestions, I’ll include them with the information I pass on to the product team.