@sierdzio no, that I understood already long ago: I have that .user file in the .gitignore of my project and do not touch it.
I think that basically there is some very low "contradiction tolerance": whenever QtCreator does not like something for whatever reason - it simply discards the entire setup. I agree that this is not very specific, and as a developer I would have problems to deal with such an "error report" ;-) However, I cannot easily specify much more.
Maybe just as an example: I am working with ParaView, and if I am doing a full rebuild of the ParaView software (which takes many hours on my system), I tend to first choose many settings in cmake-gui - because in QtCreator it is rather tedious.
<intermediate remark>For example if it has some errors during the first attempt it does not even bother to display ANY properties: You have to do the setup first with another tool, see what are the bugs (like some missing path etc.) and then manually add that property into the empty setup window in QtCreator.</intermediate remark>
But while I do the setup with cmake-gui for ParaView, I write down all the changes to options that I apply - because I am pretty sure I will have to enter them again and again! (Ok, the fact that already for the debug version you have to enter the same options once more cannot be blamed to QtCreator - it is a "feature" of cmake itself...).
After the project is properly set up with cmake-gui and "generated", both release and debug, I try to open it with QtCreator. With some other projects this was already working, and the maximum that happened was some little dialog asking whether "changes" should be accepted or rejected. But in the case of ParaView I tried it already many times throughout the last two years - and it happened really every time: the ENTIRE setup was gone after the project was read into QtCreator!
And this is where my notes on paper are coming out: I redo all the changes that I did with the cmake-gui - and again I do it twice, for both the release and the debug version.
Not sure if this is already good enough for a reproducible error report because of course I am also using specific tools on a specific system etc. etc.
In the case of ParaView, my conclusion is often most of the time: just do NOT use QtCreator at all for the build - just start ninja on the command line after the "generation".
The only disadvantage is then if I want to understand certain functionalities a bit better: then the facilities of navigating through the large code are just first class with QtCreator - and of course also a debug run requires a build that has succeeded from within QtCreator!
This just as a bit more of illustration of the struggle.